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Abstract 


NASA’s space data-communications infrastructure — the Space Netw’ork and the Ground Network — provide scheduled (as 
well as some limited types of unscheduled) data-communications sendees to user spacecraft. The Space Network operates sev- 
eral orbiting geostationary platforms (the Tracking and Data Relay Satellite System (TDRSS)), each with its own service- 
delivery antennas onboard. The Ground Network operates service-delivery antennas at ground stations located around the 
world. Together, these networks enable data transfer between user spacecraft and their mission control centers on Earth. 
Scheduling data-communications events for spacecraft that use the NASA communications infrastructure — the relay satellites 
and the ground stations — can be accomplished today with software having an operational heritage dating from the 1 980s or ear- 
lier. An implementation of the scheduling methods and algorithms disclosed and formally specified herein will produce glob- 
ally optimized schedules with not only optimized sendee delivery by the space data-communications infrastructure but also 
optimized satisfaction of all user requirements and prescribed constraints, including radio frequency interference (RFI) con- 
straints. Evolutionary algorithms, a class of probabilistic strategies for searching large solution spaces, is the essential technol- 
ogy invoked and exploited in this disclosure. Also disclosed are secondary methods and algorithms for optimizing the execution 
efficiency of the schedule-generation algorithms themselves. The scheduling methods and algorithms as presented are adapt- 
able to accommodate the complexity of scheduling the civilian and/or military data-communications infrastructure within the 
expected range of future users and space- or ground-based service-delivery assets. Finally, the problem itself, and the meth- 
ods and algorithms, are generalized and specified formally. The generalized methods and algorithms are applicable to a very 
broad class of combinatorial-optimization problems that encompasses, among many others, the problem of generating opti- 
mal space-data communications schedules. 


General Terms: Scheduling, Algorithm, Computing, Space 

Additional Key Words and Phrases: System specification, formal mathematical specification, space-data communications, ra- 
dio frequency interference mitigation, combinatorial optimization, genetic algorithm, evolutionary programming, probabilistic 
search, regression analysis 
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1. Introduction 

1.1. Background on NASA 
Data-Communications Scheduling 

Scheduling data-communications events for spacecraft that 
use the NASA communications infrastructure [26] — the re- 
lay satellites [19] and the ground stations [7] — can be accom- 
plished today with software having an operational heritage 
dating from the 1980s or earlier [10, 31] with emphasis on 
incremental and reactive scheduling [22]. Neither the legacy 
scheduling system nor any subsequent system described in 
the public literature possessed the capability to generate true 
optimized schedules for reasons that will be explained be- 
low, but the scheduling system described in publicly avail- 
able documents can (when the option was invoked) generate 
schedules free of radio frequency interference (RFI) effects 
by blocking out portions of the problem-solution space from 
consideration whenever those portions appeared with any 
predicted RFI effects. Similarly, the algorithms implemented 
in the legacy system pruned away portions of the solution 
space upon encountering violations of the various other con- 
straints. This approach, which perforce ignores large portions 
of the solution space, necessarily means that true schedule 
optimization was not an actual achievable objective of the 
legacy scheduling system. 

Present space data-communications schedulers commonly 
have the capability of algorithmically generating schedules 
using techniques for representing and exploring the problem- 
solution space as either a graph or a tree of related sub- 
solutions. A number of standard algorithms for searching a 
solution space represented as a graph or tree are available. 
These, in general, operate by eliminating branches of the tree 
where constraint violations (e.g., unacceptable levels of RFI) 
are found (although any “slash and burn” approach or any 
“branch and bound” technique has the undesirable conse- 
quence that it incorporates no mechanism by which to avoid 
discarding sections of the tree that represent solutions that are 
better than any others that can be found in the course of run- 
ning the scheduler). NASA’s legacy scheduling system, us- 
ing such standard search methods, was capable of produc- 
ing workable schedules, albeit with certain significant con- 
cessions to the compute-intensive nature of the search (in- 
cluding certain problem simplifications that themselves, even 
ignoring the performance of the search techniques, precluded 
the possibility of true schedule optimization). See Revisions 
and Changes Digest item 1, page 65. 

1.2. Toward an Optimizing Scheduler 

Current space data-communications scheduling sys- 
tems, which lack a true schedule -optimization capability. 


leave open the possibility that new methods for search- 
ing the solution space might result in improved infrastruc- 
ture performance and overall schedule-quality improvement, 
bringing increased overall customer satisfaction. 

Disclosed and formally (mathematically) specified 
herein are methods and algorithms for an optimiz- 
ing, constraint-satisfying, automated scheduling sys- 
tem that potentially could be implemented in NASA’s 
space-data-communications infrastructure. Conceived and 
developed in the early 1990s, this is the first such sys- 
tem (i.e., methods and algorithms) disclosed publicly 
that — 

1. is capable of true schedule optimization considering 
prescribed constraints such as mitigation of RF inter- 
ference, 

2. is specified rigorously, and 

3. is implementable with adequate performance. 

The system (the methods and algorithms taken together) ad- 
dresses (a) the issue of performance and efficiency of 
the communications infrastructure and (b) the impor- 
tant space-mission operations-planning problem of op- 
timizing data-communications schedules. The desired 
optimization not only would include minimizing radio fre- 
quency interference effects that can reduce achievable data 
rates for space missions, but also would include accommo- 
dating other prescribed constraints such as hours of operation 
of mission control centers and anticipated or planned re- 
source outages. 

1.3. Incorporating RF Interference-Mitigation 
Constraints 

Practically all of the major emitters that produce RFI ef- 
fects are known as to both location (or dynamic position 
in space) and signal characteristics (frequency, power, signal 
structure, polarization, etc.). There are many such sources of 
RFI: ground-based radars, radio and television transmitters, 
other spacecraft, and even cellular telephone service-provider 
towers and their customers, among other emitters. (Individ- 
ual cell phone users are each insignificant, but in the aggre- 
gate, they represent an RF noise “floor” that can be charac- 
terized, predicted, and mitigated in various ways.) 

Beyond interference mitigation techniques (e.g., spread- 
spectrum signal structures that are built into both the NASA 
data-communications infrastructure and a user spacecraft’s 
onboard hardware and software), various RFI-avoidance 
mechanisms can be invoked during the process of schedul- 
ing communications-service delivery to users. Some of 
these mechanisms do not lend themselves to automa- 
tion, while others are based on rules of thumb and problem 
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simplifications that, in general, do not promise the best pos- 
sible schedules (in terms of optimizing user satisfaction 
and service delivery by the data-communications infras- 
tructure), even if automated. The former category (i.e., 
manual mechanisms) does not represent practical ap- 
proaches for NASA, but an automated mechanism in the 
latter category (the application of rules of thumb and prob- 
lem simplifications) has been used in NASA’s scheduling 
system at least since the operational date of the Space Net- 
work. The herein-disclosed algorithm represents a third 
category of techniques for RFI avoidance in schedule gener- 
ation: it poses no difficulty for automation, is not based on 
rules of thumb (but, instead, closed-form calculations of in- 
terference effects), and supports true schedule optimiza- 
tion. 

An optimizing scheduler that satisfies constraints on RF 
interference requires prior RF analysis of the factors in- 
volved in the delivery of data-communications services, in- 
cluding the RF environment in which the communications 
occur as well as the user’s requirements and the specific 
characteristics of the user spacecraft. In the early 1990s, 
NASA’s Communications Link Analysis and Simulation Sys- 
tem (CLASS) [8]Communications Link Analysis and Simu- 
lation System (CLASS) fielded an interference analysis sys- 
tem [15] — the CLASS IAS. The CLASS software is able to 
produce all of the auxiliary data needed as input for the op- 
eration of an interference-mitigation scheduling system (see 
Section 3.1 for a representative list of these inputs). 

1.4. Concerning Processes, Methods, and 
Algorithms 

Although it represents one of the most essential concepts 
in computer science, the term “algorithm”, perhaps surpris- 
ingly, has no generally accepted technical (or formal) defini- 
tion 1 . Further, definitions of “process” and “method” typ- 
ically are non technical and imprecise. Trying to identify, 
with accuracy, distinctions between these three terms there- 
fore would be adventurous. However, for the purposes of this 
paper, we see (at least minor) conceptual differences, and 
these differences are reflected in the way the terms are used 
herein. 

A process is “a series of actions or steps taken in order to 
achieve a particular end” 2 . 

A method, considered as a “process by which a task is 
completed; a way of doing something” 3 , entails a list of steps 


1 Wikipedia article entitled “Algorithm” at http://www.wikipedia.org/ 
(accessed 18 October 2009). 

2 Oxford American Dictionaries accessed 28 October 2009. 

3 Wictionary entry at http://en.wiktionary.org/ (accessed 28 October 
2009). 


to be performed to accomplish an objective or intended re- 
sult. An algorithm, of course, also includes a list of steps to 
be performed. For the purposes of this paper, it is assumed 
that every algorithm, but not every method, can be performed 
mechanically, at least in principle. Consequently, every algo- 
rithm, but not every method, must be specifiable with preci- 
sion sufficient to make it accurately implementable as a com- 
puter program. 

In this paper, we endeavor to adhere to the following 
scheme: a sequence of steps or actions is said to be a(n) — 

1 . “Algorithm” when the steps are expected to be imple- 
mented in and performed by a computer application and 
the result of the completion of the sequence of steps is 
representable as a data structure. 

2. “Method” when the goal of the sequence of steps is 
broad or high-level and a human must perform at least 
one of the steps. 

3. “Process” when each of the steps is definite and pre- 
cisely specifiable, when a human must perform at least 
one of the steps, and when the result of performing each 
of the steps in the sequence is not necessarily repre- 
sentable as a data structure. 


1.5. The Essential Technology Used in the 
Present Disclosure 

The algorithms and methods disclosed herein apply princi- 
ples from the computer-science field of evolutionary search 
and combinatorial optimization [2, 4, 9, 30] to solve the prob- 
lem of finding an optimal overall schedule [25, 32, 12] that 
(a) will satisfy user requirements for communications sup- 
port from NASA’s communications infrastructure and (b) 
will be consistent with NASA’s Space Network User’s Guide 
(SNUG) [19] as well as the operations guidelines for the 
Ground Network [7]. The quality of the schedules generated 
by a computer application program that implements this al- 
gorithm will be a mo no tonic function of the program’s ex- 
ecution time. During the search for better and better solu- 
tions, the best solutions found so far are retained and given 
a chance to influence the creation of new, possibly better so- 
lutions. When execution is terminated arbitrarily, the output 
will be the best solution found so far during the run, and the 
longer the run, the better the solution is expected to be. More 
will be said regarding the notion of optimization (see Sec- 
tion 2.4.7 (page 15)). 

In the remainder of this paper, any mention of “the dis- 
closed algorithm” will, depending on context, be understood 
to mean “the disclosed methods and algorithms”. 


1.8 Organization of Paper 
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1.6. Innovations Disclosed 

The present disclosure incorporates well-known technolo- 
gies, namely, genetic algorithms (evolutionary search) and 
regression analysis (in the broad sense encompassing the 
general concept of the mathematical modeling of relation- 
ships between data). The primary contributions disclosed 
herein are as follows: 

1. formal specification of methods, algorithms, and pro- 
cesses for employing evolutionary-search technolo- 
gies in an optimizing scheduling system for the NASA 
space-data communications infrastructure; 

2. formal specification of a method and algorithm for op- 
timizing the internal parameters of a genetic algorithm 
(specifically the algorithms identified in item 1); and 

3. a description and formal specification of a method and 
algorithm for deriving a function that, given an arbi- 
trary problem scenario in the problem domain identi- 
fied in item 1 , will, in a cost-effective manner, return an 
estimate of the optimal values of the internal parame- 
ters of a genetic algorithm for solving the given prob- 
lem scenario. 

The author is not aware of any other disclosures equivalent 
to items 1, 2, or 3. 

Further, the methods and algorithms described and spec- 
ified formally in Appendix B (Section 11 (page 49)) gen- 
eralize those in items 1, 2, and 3 above and are applica- 
ble to a very broad class of problems. Many of the prob- 
lems in this general class (referred to as problems of Type 
G) pertain to NASA and the space program (e.g., the space 
data-communications scheduling problem treated in the main 
body of this paper, as well as space-mission design optimiza- 
tion and spacecraft-design optimization). But numerous other 
fields (particularly those related to design optimization, and, 
more broadly, virtually any field where actual solutions can- 
not be computed directly with closed-form techniques but 
can be described as finite data structures that can be evalu- 
ated as to “goodness”) are encompassed under the general- 
ized problem of Type G as defined in Appendix B. Finally, 
the formal (mathematical) specifications of the methods and 
algorithms are sufficiently rigorous and detailed to facilitate 
not only the process of relating them to this broad class of 
real-world problems, but also the process of implementing 
them in a computer-application program. (See Revisions and 
Changes Digest item 2, page 65.) 

1.7. Audience for the Present Disclosure 

As indicated above, the main body of this paper concerns 
a particular application (NASA space-data communications 


scheduling), while Appendix B broadens the topic to en- 
compass a very broad range of application domains. The 
audience for the former would include groups responsible 
for designing and implementing space-data communications 
scheduling systems (or identifying appropriate technologies 
that could be used in such systems), while for the latter the 
audience would include practitioners generally and, espe- 
cially, groups designing and implementing any system for 
reaching optimal solutions for the generalized problem do- 
mains of Type G as defined in Appendix B. Any interest in 
this paper on the part of researchers and academics would 
likely be limited to the possible application, described herein, 
of well-known techniques from the field of evolutionary pro- 
gramming, and from the field of regression analysis gener- 
ally. 


1.8. Organization of Paper 

Section 2 describes the scheduling-problem domain in terms 
of the question of tractability and identifies a viable approach 
to searching for optimal solutions. Such an approach (to the 
author’s knowledge) has not been implemented or considered 
for use in NASA’s space-data communications infrastructure, 
which is the context (or, rather, the primary context) of the 
present disclosure. Section 3 presents the assumptions under- 
lying the specification of the disclosed algorithms. Section 4 
defines general domain terms and specific notations used in 
specifying the algorithm. The algorithm itself is precisely 
specified in Section 5. Section 6 presents an additional algo- 
rithm (also based on the principles of evolutionary search) for 
optimizing the search itself — producing the optimal choice 
of the values of the schedule-generation algorithm’s internal 
parameters. In a further abstraction of the overall space data- 
communications scheduling problem, Section 7 outlines ap- 
proaches for determining a function by which to estimate the 
optimal choice of the values of the schedule-generation al- 
gorithm’s internal parameters, given a scheduling scenario. 
The prototype implementation of the schedule-generation al- 
gorithm and the internal parameter optimization algorithm 
are briefly mentioned in Section 8. Concluding remarks are 
given in Section 9. Section 10 (Appendix A) considers a 
possible model to describe the performance of the schedule- 
generation algorithm, and describes a key insight afforded by 
analysis of the model. Finally, Section 1 1 (Appendix B) de- 
scribes and specifies, in abstract terms, a broad class of prob- 
lems — one member of which is the scheduling problem of 
the kind targeted by the methods and algorithms that are pre- 
sented in the main body of this disclosure — and discloses 
and specifies generalized methods and algorithms for solv- 
ing problems in this general class. 
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2 SPACE-DATA COMMUNICATIONS-SCHEDULING PROBLEM DEFINITION 


2. Space-Data 

Communications-Scheduling 
Problem Definition 

2.1. Space-Data Communications Scheduling 

2.1.1. Scheduling-System Objective 

In the overall data-communications scheduling problem, the 
primary objective is to find a solution (i.e., a schedule) that 
(a) maximizes delivery of services to users according to their 
requirements and (b) maximizes the utilization of NASA 
service-delivery assets 4 . 

The evaluation of candidate solutions will involve numer- 
ous factors that will be described in subsequent sections. In 
addition to various technical factors, the evaluation may also 
reflect NASA policy-level considerations such as the relative 
priority officially assigned to each spacecraft or mission. 

2.1.2. Primary Factors Affecting Achievability of 
Objective 

Numerous factors bear on the achievability of the primary ob- 
jective. For example, the service-delivery assets in the data- 
communications infrastructure are subject to outages, both 
planned and unplanned. Planned outages result from equip- 
ment maintenance and upgrade activities. Unplanned outages 
are relatively rare and would include service interruptions 
due to severe weather or natural calamities like earthquakes. 
By definition, the process of searching for a solution of the 
overall scheduling problem does not incorporate unplanned 
outages. 

2.1.3. Technical Factors Affecting Achievability of 
Objective 

Technical factors, as well, bear on the achievability of the 
primary objective. These factors include any phenomenon or 
circumstance that potentially could measurably degrade data- 
communications performance: 

1 . radio frequency interference 

2. signal multipath interference 


4 The possibility of requirements for cross communications (between user 
spacecraft, or between infrastructure assets) has not been overlooked 
and is not unimportant in the foreseeable future. Such requirements are 
beyond the scope of the present disclosure, but could be readily included 
in future adaptations of the methods and algorithms specified herein. 


3. signal-to-noise ratio reduction by noise due to space- 
craft charging 5 , antenna blockage, atmospheric effects, 
rocket plume effects, etc. 

The effects of all of these factors are dynamic, but they 
can be predicted through link analysis and simulation tech- 
niques [8, 15], given a user’s planned spacecraft orbit and at- 
titude profile to enable the determination of the effects listed 
above as items 2 and 3. Item 1 is determined by the num- 
ber and characteristics (including the orbital parameters and 
attitude profile) of all other spacecraft (not only US space- 
craft but also the spacecraft flown by other nations). The pre- 
dictability of the listed effects suggests that the process of 
searching the solution space could be made more efficient 
if all candidate schedules at least avoided communications 
events rendered useless by the above factors. This strategy, 
described in general terms in [25, 33] in relation to space- 
craft mutual interference, is an integral part of the algorithm 
disclosed herein and is applicable in general to all other pre- 
dictable phenomena and circumstances that potentially could 
measurably reduce data-communications performance. Fol- 
lowing this strategy, the herein-disclosed algorithm mitigates 
these effects automatically and produces optimal solutions 
of the overall scheduling problem. In the foregoing, the word 
“spacecraft” should be broadly interpreted to include user as- 
sets of other kinds (e.g., habitats or surface rovers). 

2.2. Size of the Solution Space 

2.2.1. Determining Factors 

It is instructive to estimate, or at least establish a lower bound 
on, the size of the solution space for the data-communications 
scheduling problem for some simple combinations of users, 
user requirements, and service-delivery assets. Analysis of 
simple scheduling scenarios leads naturally to a better appre- 
ciation of how large might be the solution space for realis- 
tic scheduling scenarios. For any given scheduling scenario, 
the solution space comprises all possible schedules, each sat- 
isfying at least one requirement of at least one user. 

Each schedule consists of a set of communications events. 
Each event represents partial satisfaction of a user require- 
ment and is defined in terms of a number of parameters (most 
of which will not be discussed further herein): 

• start and end times for each forward link (when a NASA 
support antenna is radiating signals to the user asset) 


5 John Kennewell and Andrew McDonald, “Satellite Communications 
and Space Weather”, Australian Government, Bureau of Meteorol- 
ogy, Ionospheric Prediction Service Radio and Space Services, Space 
Weather Agency web site, http://www.ips.gov.aU/Educational/l/3/2 (ac- 
cessed 20 August 2008). 
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• start and end times for each return link (when the user 
asset is radiating signals to the NASA support antenna) 

• the frequency selection for each forward link 

• the frequency selection for each return link 

• the polarization of each forward link 

• the polarization of each return link 

• the data rate (or symbol rate) of each forward link 

• the data rate (or symbol rate) of each return link 

• pseudo-random-noise (PN) spread indicator for each 
forward link 

• pseudo-random-noise (PN) spread indicator for each re- 
turn link 

• NASA support-antenna selection for each forward link 

• NASA support-antenna selection for each return link 

2.2.2. A Simple Example 

The start and end times for a scheduled event have a one- 
second granularity and are represented as seconds of offset 
from some prescribed epoch (usually specified as a reference 
date such as 1 January 1970 that is “over the horizon” of past 
time in the current context). For a normal two-week schedul- 
ing period, there are 14 x 24 x 60 x 60 = 1, 209, 600 possible 
values for a start or end time. The event-duration minimum 
is nominally ten seconds and the duration maximum is nomi- 
nally 80 minutes. For a given start time, there would be 80 x 
60 — 10 = 4790 allowed intervals each representing a com- 
munications event at the given start time without violating the 
80-minute maximum limit or the 10-second minimum limit. 
If a schedule had only a single communications event with 
a single link for a given user during the two-week schedul- 
ing period, with no other constraints, there would be approx- 
imately 4790 x (1209600 - 4790/2) or 5.78 x 10 9 allowed 
instantiations of the event without violating the 80-minute 
maximum limit or the 10-second minimum limit. In a two- 
week scheduling period, with nominal duration of 90 minutes 
per orbit, there would be (14 x 24 x 60)/90 = 224 orbits. If 
in a two-week scheduling period, the given user required one 
single-link event in each orbit (see Figure 1), there would be 
224 events in the schedule. In each orbit, there would be ap- 
proximately 60 x (4790 x 10 + 4790 x 80/2) = 14, 370, 000 
possible events without violating the 80-minute maximum 
limit or the 10-second minimum limit. The number of pos- 
sible schedules — that is, the number of possible combina- 
tions of the possible events (with exactly one event in each 
of the 224 orbits) (ignoring other constraints) — would be ap- 
proximately (1.437 x 10 7 ) 224 . Thus, for this trivial schedul- 
ing scenario, the scheduling problem would have more than 


10 16 °3 p OSS ibi e solutions. Even if the maximum allowed du- 
ration of each event were reduced to 10 minutes, the cardinal- 
ity of the solution space would still exceed 10 145 °. For per- 
spective, consider this number in relation to the number of 
neutron-size spheres that could be packed into a sphere the 
size of the known universe — a number on the order of 10 135 . 


orbit orbit 
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80-minute comm events 


shorter comm events 


Figure 1. Communications events placed rel- 
ative to the 90-minute-orbit time line, as al- 
lowed in the simple example scheduling sce- 
nario. Three possible maximum-duration com- 
munications events are shown, each with a dif- 
ferent start time offset from the start of the 
orbit. Three other possible communications 
events are shown with different allowed du- 
rations and start-time offsets. In the simple 
example scenario, the user requires only one 
communications event in the orbit. 


2.2.3. A More Realistic Example 

The next factor bearing on the estimate of the size of the so- 
lution space for the TDRSS scheduling problem is the con- 
cept of the prototype event. A prototype event (to be defined 
more exactly in Subsection 4.3 (Definition 53 on page 23)) is, 
in general terms, a combination of data-communications link 
activations for actual forward and return data flows by which 
a user will accomplish various purposes, including forward 
links for delivering commands, data, and software loads to 
the spacecraft. Other purposes will pertain to returning data 
via return links to the mission control center or to scientists. 
Each of the links is defined in terms of parameters that spec- 
ify data rate, frequency, polarization, support antenna, etc. 
The specification of the values of these parameters, along 
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with the start and stop times in seconds of relative offset, and 
the allowed tolerance in these offsets, makes up the defini- 
tion of a prototype event. 

If, in a given scheduling-problem scenario, a prototype 
event has a required duration of 45 minutes and consists of 
five links, each with five allowed choices of NASA service- 
delivery antennas, and each with nominal duration of 10 min- 
utes, start-time tolerance of three minutes, and duration tol- 
erance of three minutes, then in comparison with the above 
example (a single spacecraft requiring one event per orbit), 
the size of the solution space (or its lower bound) would be- 
come a much larger number. This number is roughly calcu- 
lated by first calculating the number of possible instances 
of each prototype event that could be instantiated for any 
given prototype-event start time, and then calculating the 
number of possible instantiations of the prototype event in 
a given orbit. Allowing any start time that does not exceed 
45— (10+3) = 32 minutes of offset from the prototype-event 
start time, the number of possible instantiations of one of the 
links (ignoring the choices for service delivery antenna) is 
60 x 32 x 60 x ((10 + 3) - (10 - 3)) = 691200. Allowing 
any start time offset between 32 minutes and 45 — (10 — 3) = 
38 minutes from the prototype-event start time, the num- 
ber of possible instantiations of one of the links (ignoring 
the choices for service-delivery antenna) is approximately 
60 x (38 - 32) x 60 x ((10 + 3) - (10 - 3))/2 = 64800. 
The minimum allowed duration of a link represents a con- 
straint to ensure that a link is not allowed to start with an 
offset of more than (in the present example) 38 minutes. 
Thus, for a given instantiation of the prototype event, the to- 
tal number of allowed instantiations of one of the links (ig- 
noring the choices for service-delivery antenna) would be 
691200 + 64800 = 756000. 

To simplify calculations and yet establish a lower bound 
on the number of possible instantiations of the given proto- 
type event, assume there is only one allowed start time for 
a prototype event in each orbit (although, typically, the al- 
lowed start time for a 45-minute prototype event would be 
any time in the first 45 minutes of the 90-minute orbit, so 
that there would be 2700 different allowed start times in 
each orbit). Then the number of possible instantiations of 
the prototype event per orbit — each instantiation being an al- 
lowed combination of five prototype-event links — would be 
756000 5 = 2.469 x 10 29 . Therefore, the number of possi- 
ble combinations of prototype events in the 224 orbits in the 
scheduling period would exceed (10 29 ) 224 = 10 6496 . 

Thus, with consideration of all possible solutions allow- 
ing all possible combinations of prototype events for multi- 
ple users, with all possible combinations of allowed choices 
of data rate, frequency, polarization, support antennas, etc., it 
quickly becomes apparent that the solution space for a real- 
istic scheduling scenario would be much larger yet. 


Prototype event 
start end 

0 15 30 45 minutes 


TDRS-8 MA 
TDRS-5 SA2 
TDRS-8 SA1 
TDRS-5 SA1 
TDRS-5 MA 

Figure 2. An example prototype event for 
a more realistic communications scheduling 
scenario. The user’s specification for a proto- 
type event requires five links established and 
completed between the start time and end time 
of the prototype event. Each link has allowed 
tolerances on start time and duration, and has 
one of five allowed service-delivery antennas 
assigned to it (e.g., the TDRS-5 SA2 antenna). 
The user requires that an instance of the pro- 
totype event is to be scheduled relative to 
some prescribed mission event (e.g., the start 
of an orbit), with some prescribed tolerance on 
the start time. 


2.2.4. Possible Approach to Reducing the Size of the 
Solution Space 


A reduction of the size of the solution space could be real- 
ized by increasing the granularity of the allowed start times 
and durations for events. For example, one might allow only 
even-numbered seconds of offset from the prescribed epoch. 
At best, this would reduce the size of the solution space in the 
above simple example by a factor of (2 -5 ) 224 = 2 -1120 , or 
10 -337 , from 10 6496 to a number that yet still exceeds 10 6159 . 
Such an approach, if it results in a significant reduction in the 
size of the solution space, will not effect a tractable prob- 
lem without at the same time effectively eliminating the pos- 
sibility of finding optimal solutions. Making optimal solu- 
tions less likely (or impossible) to be found does not repre- 
sent an attractive characteristic of an approach for reducing 
the size of the solution space: enabling worse solutions to be 
found faster presents a dubious gain. 
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2.3. Alternative Approaches 

2.3.1. Brute Force and Constructive Techniques 

From the very large size of the solution space — even for 
very simple scheduling scenarios as trivial as the above ex- 
amples — it becomes clear that the feasibility of finding op- 
timal schedules will depend on the feasibility of a method 
that does not rely on brute -force search (i.e., a search strat- 
egy that requires the examination/evaluation of every possi- 
ble solution (i.e., every possible schedule)). Inescapably, only 
an exceedingly large number could represent the size of the 
solution space for real-world scheduling scenarios for the ac- 
tual users of NASA’s space data-communications services, 
and the idea of examining all of the possible solutions is un- 
tenable without resorting to some truly exotic method, such 
as the yet-to-become-practical idea of quantum computing. 
The general problem of creating optimal schedules to satisfy 
users’ data-communications requirements cannot be solved 
using a single, general prescriptive formula, nor with brute- 
force search through the solution space, even with power- 
ful computers (possibly excepting future quantum comput- 
ers) and the most sophisticated graph or tree -traversal algo- 
rithms (such as the A* algorithm [3, 22] (not to be confused 
with the set of all antenna IDs (Definition 36 (page 21)))). 
From the foregoing examples, it will have been seen that the 
general optimal-solution search problem cannot be attacked 
with such approaches. 

However, workable solutions can be generated with the 
techniques that are in use in the current operational schedul- 
ing system, and these solutions are free of violations of con- 
straints (e.g., RF interference, if this option is activated in the 
scheduler). However, there is no expectation that the current 
operational approach will produce solutions that are near op- 
timum. Further, since an optimum solution (in the absolute 
sense) would necessarily remain unknown, it cannot be de- 
termined how nearly optimum these found solutions might 
be (and even if an upper bound on the difference could be 
calculated, it would be without benefit, since the approach of 
the present operational system offers no way to use the infor- 
mation to produce better schedules). 

2.3.2. Necessity of Special Search Techniques 

From the foregoing, it becomes a convincing proposi- 
tion that neither a brute-force strategy nor the approach 
of the current or any previous NASA scheduling sys- 
tem can offer the possibility of discovering an opti- 
mal solution for realistic scheduling scenarios: other 
techniques are required. While brute-force search per- 
formed using quantum-computing techniques might be 
explored in the future, a more immediately available ap- 
proach is worth considering for the interim. Research and 


application experience since the 1980s has resulted in es- 
tablishing the viability of probabilistic search strate- 
gies for certain types of optimization problems that have 
very large solution spaces. In particular, genetic algo- 
rithms [2, 4, 9, 30] (or, more generally, evolutionary 
algorithms) have been successfully applied to schedul- 
ing and planning problems [1, 5, 13, 17, 28, 29, 32]. While 
other probabilistic search strategies (including those un- 
der the heading of regression-analysis techniques) are in- 
voked at a high level herein (see Sections 7.2 and 11.5.2), 
their detailed treatment is beyond the scope of this disclo- 
sure. 

2.4. Evolutionary Search 

2.4.1. Genetic Algorithms 

Genetic algorithms belong to a well-studied class of algo- 
rithms abstractly inspired by biological selection and gen- 
eration, individual inheritance and mutation, species adapta- 
tion, species survival, and fitness [11]. Both in the algorith- 
mic realm and in biology, selected individuals in each gener- 
ation mate and produce offspring. The offspring have some 
but not all of the traits of their parents, and in fact have new 
traits as a result of genetic crossover and mutation. Individ- 
uals die and make way for individuals in the new genera- 
tion, who will survive better or not, depending on their fitness 
for survival in their given environment — which environment 
will favor the more-fit individuals with more power to pro- 
duce offspring for the next generation. Over successive gen- 
erations, the principle of “survival of the fittest” implies the 
expectation that the survival of individuals will improve over- 
all, i.e., the average fitness of members of the population will 
improve progressively. 

2.4.2. Representations of Solutions of the Scheduling 
Problem 

The present disclosure invokes the principles of genetic algo- 
rithms to attack the problem of scheduling space-data com- 
munications, with the incorporation of the further, secondary 
objective of minimizing the effects of RF interference in the 
optimization. (Note that this further objective represents a 
primary example of the general constraint-satisfying capa- 
bilities of the disclosed algorithms and methods.) Under the 
conceptual description given above, a solution, by definition, 
is a schedule. The question of how to represent a solution for 
the purpose of searching the entire solution space for an op- 
timal solution is fundamentally important, and has an imme- 
diate answer. The answer, since every solution in the solution 
space is a schedule, is that a solution is a finite data struc- 
ture in computer memory that represents a schedule, which, 
by definition, is simply a list of communications events each 
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of which at least partially satisfies at least one user require- 
ment for communications services. The combined data struc- 
ture that represents the whole evolving population of candi- 
date solutions at a given iteration of the running search pro- 
cess is just the combined list of individual members of the 
current population. The data structure for any individual (be- 
ing one possible solution of the entire scheduling problem) 
is subjected to evaluation by a fitness function that deter- 
mines the individual’s survivability or fitness, i.e., the degree 
to which the individual measures up to prescribed criteria for 
selection as a member of, or to produce offspring for, the next 
generation. 

2.4.3. Processes for Selection and Creation of Working 
Population Members 

The fitness function is the essence of the problem to be 
solved by the genetic algorithm and remains unaltered for 
the duration of the entire search for a solution. Each member 
(i.e., each schedule) of a given generation would have a fit- 
ness score determined by the prescribed fitness function. In 
each generational cycle, to prepare a new generation, a pre- 
scribed process (sub-algorithm) operates to perform a selec- 
tion of individuals (schedules) to survive into the new gen- 
eration and/or to be used to generate offspring. Another pre- 
scribed process (sub-algorithm) then (a) creates the offspring 
of the selected individuals by mathematically transforming 
and combining their traits (i.e., the values in the data struc- 
ture representing an individual), and (b) adds new members 
using an algorithm for randomly generating new schedules, 
to effect the probabilistic exploration of the entire solution 
space. The probabilistic nature of the exploration arises from 
the use — during the execution of both the selection process 
and the new-member-creation process — of random-number 
generators in the computing platform on which the genetic 
algorithm executes. More will be said in Section 2.4.9 con- 
cerning random numbers in relation to the algorithms dis- 
closed herein. 

2.4.4. Principle of Operation of Genetic Algorithms 

Operation of the genetic algorithm begins with the creation 
of an initial population of some size. The manner in which 
the members of the initial population are generated can af- 
fect the search progress, although the nature of the algorithm 
tends to diminish the effect over the course of the search. A 
new generation results from applying a variety of mathemat- 
ical transformations not only to individuals (i.e., their data 
structures), but also to pairs of individuals in the current gen- 
eration, which each will already have been evaluated by the 
fitness function during the process of selecting the members 
of the previous generation to compose the current generation. 


The more-fit individuals, being relatively favored (and, con- 
sequently, more likely themselves to persist for multiple gen- 
erations), will have relatively more offspring than will result 
from less-fit individuals. However, randomly selected indi- 
viduals will also produce offspring at some rate, and new in- 
dividuals randomly created are also introduced into the pop- 
ulation at some rate. The new generation will then undergo 
the same process of evaluation and transformation to result 
again in a new generation. After some number of repetitions 
of the foregoing generational process, the current generation 
will, with some likelihood, include individuals that are more 
fit than the best members of any previous generation. Even- 
tually, after many generations, the expectation is that an ad- 
ditional iteration of the evolutionary search process will have 
a vanishingly small likelihood of producing further signifi- 
cant improvement of the best individuals of the new gener- 
ation over those of the previous generations (see Footnote 6 
(page 46)). 

2.4.5. Progress of Evolutionary Search 

After an expected initial rapid improvement in the fitness of 
the best individuals, each successive generation will see, on 
average, less and less improvement. There occasionally can 
be sharp improvements from one generation to the next. Such 
improvements can occur by virtue of the probabilistic nature 
of the genetic algorithm-based search strategy: occasionally, 
during the search, a newly created individual (schedule) will, 
by chance, be much better (as evaluated by the fitness func- 
tion) than any other individual found earlier in the search. In 
this way, the algorithm can find and explore another region 
with a local minimum/maximum — which, with some prob- 
ability, could be the global minimum/maximum. However, 
the search effort/time required to produce significant new im- 
provement in the best individuals eventually will become un- 
tenable. Ultimately, the search must be terminated and the 
best individual (or rather one of possibly multiple individ- 
uals having the same best value of the fitness score) would 
then be used as the search result — with no guarantee, how- 
ever, that this solution is in fact the absolute best, and, fur- 
thermore, with no good way to show that it is not. 

Exploration of the solution space using a genetic algo- 
rithm may entail certain difficulties that have been described 
in the literature, e.g., “premature convergence” and “genetic 
drift”. A determination of the degree to which such diffi- 
culties might be present in the disclosed methods and algo- 
rithms has not been undertaken and is beyond the scope of 
this paper. However, the disclosed methods and algorithms 
include the S® Algorithm (Section 6 (page 37)) that directly 
addresses these issues, effectively “tuning” the genetic algo- 
rithm that finds an optimal solution for a given space-data- 
communications-scheduling problem scenario. Further, Sub- 
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section 1 1 .4 (page 54) presents methods and algorithms that 
effectively address similar issues relative to solving the gen- 
eralized problem. 

2.4.6. Effect of Internal Parameters of the Genetic 
Algorithm 

A genetic algorithm, in the general case, has internal param- 
eters that affect the efficiency and effectiveness of the search, 
including — 

• the size of the initial population 

• the size of subsequent generations 

• the proportion of each generation that is selected ran- 
domly for survival into the next generation 

• the number of offspring produced by selected individu- 
als 

• the number of randomly created individuals added to 
each new generation 

• the mutation rate, (i.e., the number of new members cre- 
ated in each new generation via the mutation mecha- 
nism) 

• the crossover rate, (i.e., the number of new members 
created in each new generation via the crossover mech- 
anism) 

• the number of “gene” crossover points (where, infor- 
mally, “gene” refers to values in the data structure that 
specifies an individual member of the population 

It is natural to ask how best to set the values of the inter- 
nal parameters when the objective is to run an implementa- 
tion of the algorithm and achieve the greatest possible degree 
of effectiveness and efficiency in generating an optimal so- 
lution to the scheduling problem. Some understanding of the 
effect of different combinations of the possible values of the 
parameters can be gained through systematic experimenta- 
tion — testing different combinations to reveal how they af- 
fect the efficiency and effectiveness of the search process. 
Such a process, if performed manually, would be time con- 
suming and tedious. It also might present conceptual and the- 
oretical difficulties relative to drawing reliable conclusions. 

By asking what might be the best combination of the val- 
ues of the internal parameters, one then sees another, some- 
what more abstract optimization problem. The author’s im- 
plementation of the unpublished predecessor of the herein 
disclosed algorithm included the use of a genetic-algorithm 
approach to solve this problem as well, to derive an optimal 
combination of those values. Details of this optimization ap- 
proach are found in Section 6 for the schedule-generation al- 
gorithm to be presented in Section 5 and (relative to the gen- 
eralization of the algorithms and methods that will be pre- 


sented in the main body of this disclosure) in Appendix B 
(Subsection 11.4 (page 54)). 

2.4.7. Fitness Functions, Minima, Maxima, and Optima 

The fitness function applied to an individual (i.e., a sched- 
ule) in a given generation will produce a numerical value. 
In principle, the fitness score could be determined for ev- 
ery schedule in the entire solution space. If this were done, a 
kind of hypersurface (representing the fitness score (the de- 
pendent variable) as a function of the schedule (the indepen- 
dent variable)) could be constructed and analyzed mathemat- 
ically, and could be visualized as having contours, peaks, and 
valleys. The visualization of the function would also exhibit 
discontinuities resulting from, for instance, the discreteness 
of the allowed values for many of the parameters in the def- 
inition of a communications event. The sheer magnitude of 
the size of the solution space makes such a surface infeasible 
to construct, but the very class of probabilistic exploration al- 
gorithms we are concerned with in this disclosure could (if 
desired) even be used to approach the question of character- 
izing how “nice” the hypersurface is. In any case, the dis- 
closed algorithm is well suited to exploration of the whole 
solution space, “nice” or not. 

The essence of the optimization question pertains to find- 
ing the global maximum (or the global minimum, depending 
on how the fitness function is defined) of the search space. 
No known practical method exists to reach an “absolute” an- 
swer to this question for the general case. At this writing, 
no other available method has been shown to surpass the re- 
sults that can be attained through a method based upon evo- 
lutionary (probabilistic) search: no known non-probabilistic 
method for addressing the general scheduling problem has 
been shown to be capable of surpassing the results that can 
be attained using available probabilistic search methods. 

The term optimizing, as applied to the algorithms de- 
scribed herein, reflects this aspect of directed, iterative prob- 
abilistic search, where the search space is probed by a ran- 
dom process to find more and more minima/maxima (local 
as well as global), and by another process that gives each 
of the best candidate solutions from the current generation a 
chance to have “children” that are still more fit as solutions 
to the scheduling problem. 

In general, the nature of the problem, with its extremely 
large solution space, leaves open the possibility that, at the 
termination of any arbitrarily long run of the application pro- 
gram on a computer, a “better” solution might have been 
found by letting the application produce just one more gener- 
ation. When the run is terminated, the best solution found is 
considered to be optimized in terms of the probabilistic cov- 
erage of the entire search space. This is the primary sense in 
which the term “optimal” is used in this disclosure, but there 
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is, in a practical vein, an additional consideration, namely, the 
cost of the process of searching through the solution space 
for the best possible solution. Absent any limit on the speed 
or storage capacity of computing resources, there would be 
no trade-off between solution quality and search time. Actual 
limits on computational speed and storage will necessarily 
mean that, for any computer application that solves the kind 
of optimization problems addressed herein, solution optimal- 
ity will be directly related to the duration of the run of the ap- 
plication, which can never be unbounded. Thus, the designa- 
tion of “optimal” implies that enough computing power has 
been applied to reach a point where the law of diminishing re- 
turns (or at least a similar principle; see Footnote 6 (page 46)) 
would mean that a relatively large additional search effort 
would not have any significant expectation of improvement 
in the best solution found to that point. Conversely, if such a 
point has not been reached, then nothing can be asserted as 
to the optimality of any solution found. 

An unavoidable issue arises from the above dis- 
cussion — the question whether it could be determined 
in advance what computing resources would be suffi- 
cient to reach the point described in the preceding para- 
graph (i.e., the point where it would be legitimate to de- 
clare that no reasonable additional search time would 
provide any reasonable expectation of significant improve- 
ment in the solution found). No known method can answer 
this question, except the empirical method, i.e., experi- 
mentation, although the kind of algorithm-performance 
modeling described in Appendix A may afford additional in- 
sights. 

2.4.8. Metrics for Evaluation of the Scheduling System 

Possible metrics to evaluate a scheduling system include 
(a) determining the percentage utilization of service-delivery 
assets (e.g., TDRSS antennas) and (b) assessing the de- 
gree of satisfaction of customer requirements. In general, 
closed-form algorithms and techniques (including construc- 
tive techniques and graph-search techniques) do not afford 
in a scheduling system a strategy for directly optimizing, in 
the true sense, these metrics or indeed any other metrics. The 
herein disclosed algorithm, based upon probabilistic search, 
lends itself to incorporation of, and optimizing, a wide range 
of possible combinations of metrics to meet future goals for 
overall infrastructure performance. However, a full discus- 
sion of the possible metrics for evaluating the scheduling sys- 
tem is beyond the scope of this disclosure. (See Revisions and 
Changes Digest item 3, page 66.) 

Directly comparing the current operational system with 
one following the present disclosure might be accomplished 
by evaluating schedule quality using the herein disclosed fit- 
ness function (see Definition 102 (page 32)) or a combination 
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of its constituent submetrics (e.g., the function satisfied (see 
Definition 100 (page 31)), which measures the degree of sat- 
isfaction of data-return requirements of all users.) 

2.4.9. Random Numbers and Their Role 

Random numbers play a crucial role in the probabilistic 
search strategy and algorithms embodied in the present dis- 
closure, including the schedule-generation algorithm (Al- 
gorithm 1 (page 35)) and the S : algorithm (Algorithm 2 
(page 35)), as well as algorithms in Appendix B (Section 11 
(page 49)). 

It is noted that “random” numbers are generated by spe- 
cial software or hardware on the platform that constitutes 
the computing resources on which an implementation of the 
herein disclosed algorithms will run. On typical platforms, 
the random-number generator implements a special algo- 
rithm that can be configured with a “seed” as the starting 
point for calculations to produce a random number. Repeata- 
bility of results can be assured by selecting the same seed 
for repeated runs — which is a feature that supports applica- 
tion software testing and debugging. The generated random 
numbers are not truly random, which is a well recognized as- 
pect of all known algorithms for generating random numbers. 
Interestingly, characterizing the difference between the out- 
put of random-number generators and the output of true ran- 
dom processes is not a settled matter, necessarily involving 
arcane argumentation. 

The fact that the generally available random-number gen- 
erators do not produce “true” random numbers does not in- 
validate their use in ordinary applications (such as the one 
described in this disclosure), where their use is generally ac- 
cepted. We accept the proposition that the use of a true (or at 
least the best possible) random-number generator would not 
improve the results or performance of a system that imple- 
mented the algorithms disclosed herein. 

3. Communications-Scheduling 
Assumptions 

3.1. Necessary Input Data 

The disclosed method and algorithm assume the availability 
of inputs from a computational resource that provides the fol- 
lowing information: 

• predicted user-communications view periods relative to 
each NASA support antenna 

• user-spacecraft orbit start and end times, with orbit 
numbers 
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• start and end times for intervals during which the user’s 
Project Operations Control Center (POCC) (or, synony- 
mously, Mission Operations Control Center (MOCC)) 
is in operation 

• start and end times for other relevant mission events 
(user-spacecraft sunrise, user-spacecraft-over-land, 
etc.) whenever there are active user requirements that 
specify any relationship to such events 

• potential-interference intervals (predicted intervals dur- 
ing which RF signal interference would prevent NASA 
from satisfying a particular user requirement or request 
for communications services) 

• intervals of predicted user-antenna blockage and multi- 
path interference with respect to each support antenna, 
based on planned user-spacecraft attitude profiles 

• outage intervals (predicted/planned intervals dur- 
ing which service-delivery resources will be unavail- 
able) 

Such a computational resource, the Communications Link 
Analysis and Simulation System (CLASS) [8, 15, 20], has 
been in operation at the NASA Goddard Space Flight Center 
since the early 1980s. The CLASS system was used in gener- 
ating input data for runs of the prototype implementation of 
the predecessor of the disclosed algorithm, which implemen- 
tation is described in Section 8.1. 

3.2. Scope Limitations 

3.2.1. Two- Week Scheduling on a Weekly Cycle 

NASA’s present operational scheduling system per- 
forms the scheduling function on a weekly basis for a 
two-week scheduling period. The second week of the pre- 
viously generated two-week schedule becomes the first 
week of the new two-week schedule and is adjusted by the 
scheduling system to reflect updated or revised informa- 
tion concerning user requirements, planned outages, and 
other factors. The second week is scheduled afresh. Al- 
though it was not a design goal of the algorithm disclosed 
herein, it could be revised to provide this rescheduling func- 
tionality. However, it may be appropriate to reconsider the 
need for a two-week scheduling cycle when a new opti- 
mal schedule could efficiently be generated weekly (or 
on demand) by means of the method and algorithm dis- 
closed herein. 

3.2.2. Dynamic Rescheduling 

Although NASA’s present operational scheduling system can 
perform rescheduling under dynamic operational conditions 
(where, for example, a spacecraft has a declared emergency. 


or a service-delivery resource has an unplanned outage), 
rescheduling is not considered herein and does not corre- 
spond to a design goal of the disclosed algorithms. Further 
discussion of dynamic rescheduling is beyond the scope of 
the present disclosure, but it has not been seen to present 
technical difficulties in a possible revised version of the dis- 
closed methods and algorithms. 

3.2.3. Near-Earth Communications Environment 

NASA has been pursuing goals for crewed (as well as new 
un-crewed) missions that may be developed to explore the 
Moon and Mars over the next several decades. Such mis- 
sions crucially depend on adequate communications involv- 
ing RF links between the Earth and numerous remote as- 
sets including the mission vehicles and habitats. The future 
evolved infrastructure to provide the needed communications 
capabilities is in the early stages of definition, but is likely 
to have considerable similarities to the current space data- 
communications infrastructure serving near-Earth missions. 
For example, it is likely to have capabilities for “demand ac- 
cess” as well as a large reliance on scheduled communica- 
tions events, where infrastructure support antennas and as- 
sociated equipment would be scheduled to be configured to 
support user assets. While it was not a specific design goal 
to include the non near-Earth infrastructure in the disclosed 
methods and algorithms, the essential concepts already em- 
bodied in the present near-Earth infrastructure would con- 
tinue to be applicable. The one major issue that would need 
to be addressed for the non near-Earth infrastructure pertains 
to RF signal latency due to the large distances involved, es- 
pecially between the Earth and Mars. 

4. Definitions 

4.1. Basic Space-Data-Communications 
Definitions 

CLASS — Communications Link Analysis and Simulation 
System. CLASS is a software system developed, main- 
tained, and operated at NASA Goddard Space Flight 
Center for the purpose of supporting all aspects of space 
communications including spacecraft and communica- 
tions infrastructure design and operations. (See Subsec- 
tion 1.3 (page 7) and Subsection 3.1 (page 16).) 

Communications View Period — A time interval dur- 
ing which a given NASA service delivery antenna 
is capable of being pointed toward a given user as- 
set (spacecraft, rover, etc.), with a clear RF path that 
will permit data transfer using radio signals that have 
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prescribed characteristics (frequency, power, polar- 
ization, etc.)- (See formal definition of M (and the 
explanation). Definition 46 in Subsection 4.3, page 22.) 

Epoch — A date and time specified precisely and used as 
a reference time to specify later points in time as off- 
sets from the epoch. For example, a NASA mission may 
specify time as seconds of offset from the epoch date 
and time of 00:00 Hours on 1 January 1970. 

Forward — The direction of data flow from a NASA sup- 
port antenna to a user asset (spacecraft, rover, etc.). 
(Note that this definition may admit some ambiguity 
under various operational circumstances using particu- 
lar protocols (e.g. “acknowledgment” protocols as used 
in standard communications networks). The term is es- 
sentially meaningless in the context of two-way voice 
communications over a space communications link.) 

Link — An established RF connection between a transmit- 
ter and receiver configured with compatible signal fre- 
quencies, polarization, framing, coding, and data for- 
mats, with sufficient received signal power to enable 
data transfer. The description of such a connection. 

MA — Multiple Access; identifies the electrically “steer- 
able”, phased-array antenna on a TDRS spacecraft. 
MAF/MAR (MA Forward/Return). See definition of 
SA. 

MOCC — Mission Operations Control Center. A facility 
housing personnel, equipment, software systems, and 
other resources, with necessary communications inter- 
faces with external entities, for the control and opera- 
tion of a space mission. Synonymous with Project Op- 
erations Control Center (POCC). 

Outage Interval — A planned or anticipated interval during 
which a service-delivery resource will not be in service. 
This includes intervals designated for equipment main- 
tenance, upgrade, or calibration. (See formal definition 
of O, Definition 39 in Subsection 4.3, page 21.) 

POCC — Project Operations Control Center. Synonymous 
with Mission Operations Control Center (MOCC). 

Potential Interference Interval — A predicted interval dur- 
ing which unacceptable RF interference would affect 
signals received by either a user antenna or a service- 
delivery antenna. (See formal definition of I, Defini- 
tion 49 in Subsection 4.3, page 22.) 

Priority — A NASA-assigned numerical value that estab- 
lishes the order of precedence of a given user relative 
to others, for the purpose of determining which of any 
two users will have precedence whenever they are in dy- 
namic contention for NASA communications services. 


(See formal definition of <!>, Definition 50 in Subsec- 
tion 4.3, page 22.) The priority value is increased when 
a user has a declared contingency (e.g., the unexpected 
failure of a gyroscope on a spacecraft), although such 
a circumstance is not relevant for a scheduler, since by 
definition a declared contingency is not planned. 

Return — The direction of data flow from a user as- 
set (spacecraft, rover, etc.) to a NASA support antenna. 
(See remark under “Forward” regarding ambigu- 
ity of the term in certain circumstances.) 

SA — Single Access; refers to the two steerable dish an- 
tennas on a TDRS spacecraft. KSAF/KSAR (K-band 
SA Forward/Return). SSAF/SSAR (S-band SA For- 
ward/Return). See definition of MA. 

Schedule — A collection of communications support events 
placed on a time line for a given time period (typically 
two weeks) and identified by a set of parameter values 
that enable the NASA communications infrastructure to 
be properly configured to provide communications ser- 
vices to users. (See formal definition of 0 in Subsec- 
tion 4.3, page 26.) 

User — A spacecraft or (depending on context) its as- 
sociated mission project that is authorized and 
properly configured to make use of NASA space 
data-communications services. A user can also be a 
rover on the surface of the Moon, or a special de- 
vice on the Earth’s surface designed to enable calibra- 
tion of TDRSS ranging capabilities. An example of a 
user is the Hubble Space Telescope. 

User Requirement (or User Request) — A specification of 
data-communications services needed by a user. Such 
a specification can be either specific or generic. Spe- 
cific requirements give start time and end time either 
as absolute times (e.g., as a date and time in the Ju- 
lian calendar or as seconds of offset from a prescribed 
epoch) or as seconds of offset from a prescribed mission 
event (e.g., spacecraft sunrise in orbit number 694). A 
generic requirement represents a repeating support ser- 
vice, with start and end times always defined in terms 
of a repeating mission event such as spacecraft sunrise. 
For both specific and generic requirements, the specifi- 
cation refers to some user-defined prototype communi- 
cations event (see formal definition of C, Definition 53 
in Subsection 4.3, page 23), which defines the commu- 
nications links required for each instance of the event, 
along with other relevant parameters. 

4.2. General Notation 

The formal specifications of the herein disclosed algorithms 

depends on precise mathematical notation (in particular, set- 


18 


4.2 General Notation 


4 DEFINITIONS 


builder notation ) involving a number of general terms and 
symbols defined in this subsection. 

In set-builder notation, a set may be specified by using 
“curly braces” to enclose a list of its elements. For exam- 
ple, the set A consisting of the squares of the first five count- 
ing numbers could be specified as A = {1, 4, 9, 16, 25}. Al- 
ternatively, a set may be specified using the “set builder” no- 
tation, by which the same set could be specified as (ir : x 
is the square of one of the first five counting numbers} or 
{x : 3i G N + 3 i < 6,i = i 2 }, which translates to En- 
glish as “the set to which x belongs if and only if there ex- 
ists i belonging to the set of all positive integers such that i is 
less than 6 and x is the square of i”. 

A fundamental concept in logic is that of logical nega- 
tion, denoted by the symbol -■ (pronounced “not” or “being 
not true that”). -> has the meaning of “not” in a logical ex- 
pression. The expression ->x has a value opposite the logi- 
cal value of x: that is, the expression is “true” if x is “false” 
and “false” if x is “true”. 

(See item 4 (page 66) in Revisions and Changes Digest.) 

Definition 1: • (pronounced “bullet”) is a placeholder sym- 
bol representing any allowed value in the indicated place in a 
formula or expression, without regard to which allowed value 
might be chosen. 

Definition 2 (Universe): 12 is the universe of discourse, i.e., 
the set of all objects that can be a member of a set defined in 
the present disclosure. 

Definition 3 (Empty Set): 0 denotes the empty set, i.e., the 
set that has no member. 

Definition 4 (Set of All Integers): Z is the set of all integers. 

Definition 5 (Set of All Nonnegative Integers): N is the set 
of all nonnegative integers. 

Definition 6 (Set of All Positive Integers): N + is the set of 
all positive integers. 

Definition 7 (Set of all real numbers): R is the set of all real 
numbers. 

(See Revisions and Changes Digest item 6, page 66.) 

Definition 8 (Cardinality): \/Q C 12, Q denotes the cardi- 
nality of Q (i.e., the number of members of Q). n = |Q| •o- 
n G N and Q has exactly n members. 

Note that |0| =0. 

Definition 9 (Power Set): MQ C fi, p(Q) denotes the power 
set of Q, i.e., y G p(Q) y C Q. 

The power set of Q is the set of all subsets of Q. (See Revi- 
sions and Changes Digest item 7, page 66.) 


Definition 10 (Set of All Finite Sets): 

12 F C p(12) 9 Q G Up 44 3n G N 3 \Q\ = n. 

Dp is the set of all finite sets. 

Definition 11 (Cartesian Product): VA,33 C 12, the Carte- 
sian product A x 73 = | (a, 6) : a G A, 6 G 7?|, i.e., A x 73 

is the set of all ordered pairs (a G A, b G 73). MQ C 12, Q 2 = 
Q x Q. [Q C 12, 2 < n G N] => Q n = Q x Q n ~ 1 . 

Definition 12 (Function): VA, 73 C 12, / is said to be a func- 
tion from A to 73, denoted by /: A — > 73, if and only if 
/ C A x 73 9 (a, 6), (a, c) G / => b = c. A function is con- 
sidered to be a mapping from a domain to a codomain. If 
/ is a function, dom(/) denotes (a: (a,*) G /}, the do- 
main of /, and codomain(/) denotes {b: (•. h) G /}, the 
codomain of /. 

Definition 13 (Set of All Functions From Y to X): 

VI,ycil,I r =|/:[/:F9 X] j, the set of all 
functions from Y to X. 

Note that in some contexts (when not each of X and Y is 
a set), the meaning of X 5 differs (e.g., see Definition 56 
(page 24)). Note also that X and Y in this context are free 
variable names, not to be confused with any domain-specific 
objects defined later. 

Definition 14 (Function composition): 

[X,Y,ZCQJ ex Y ,geZ x ] => gofeZ Y . 

The symbol o (read as “circle” or “composed with”) denotes 
“function composition”, representing the process of using the 
output of one function as the input to another. In performing 
the process for a given value a in Y (the domain of /), the 
function / is used to obtain the value /(a) (a value in X (the 
codomain of /)), and this output from / is used as the in- 
put to the function g (whose domain is X) to obtain the value 
g{f{a)), which is a member of Z, the codomain of g. Thus, 
gof is a function mapping Y to Z. (Note that X, Y, and Z in 
this context are free variable names, not to be confused with 
any domain-specific objects defined later. Also, note that free 
variable Z is not to be confused with Z, the set of all inte- 
gers (see Definition 4, page 19).) See Revisions and Changes 
Digest item 5, page 66. 

Definition 15 (set difference): VQ C 12, VA C Q. Q\A = 
{x G Q : ~>x G A}, the set of members of Q that do not be- 
long to A. 

Q\A denotes set difference. 

Definition 16 (Set of All Integer Intervals): Given integers 
a, b G Z 9 a < b, the integer interval [a, b] is the set of all in- 
tegers between and including a and b. Z is the set of all inte- 
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ger intervals, that is, Z = (i C Z : 3a, b £ Z 3 a < b and 

Note that in this disclosure, the notation [a, 6 ] can apply to ei- 
ther integer intervals or closed intervals of real numbers, de- 
pending upon context. In some contexts, square brackets are 
only typographical grouping marks, similar to parentheses 
and curly braces. See Revisions and Changes Digest item 8 , 
page 66 . 

Definition 17: mdint :ZxZ-tZ3j,j6Z,!<j=> 

rndintL, j) is a random integer in the closed interval [i,j]. 

rndint is a “pseudo-function” in the sense that, in any two in- 
vocations for the same arguments, it does not necessarily re- 
turn the same result, assured by the use of a randomizing 
mechanism in the processing system on which the applica- 
tion is running. 

A further note concerning functions is in order: except 
when a “pseudo-function” like rndint is involved, the mem- 
bers of the mapping (the ordered pairs) are fixed. 

Definition 18 (Left-Most and Right-Most Points of an Inter- 
val): V ?7 = [a, b] £ Z, rj~ = a and ?; + = b. 

Definition 19 (Ordering Relation for Intervals): 

V? 7 , /? £ Z, 17 < /3 r) + < /3~ . 

This is the ordering relation for intervals. 

Definition 20 (Ordering Relation for Sets of Intervals): 

VA, B £ p(Z), A < B <=> [rj £ A, P £ B => T) < /3]. 

This is the ordering relation for sets of intervals. 

Definition 21 (Sequence): s is said to be a sequence if and 
only if 

S £ fl N 3 

1. 3a £ 0 3 (0, a) £ s and 

2. ( j € N+, •) £ s => 36 £ Cl 3 (j - 1, b) £ s. 

Note that the first element of a sequence has index value 
0, and that no index value is skipped. See Revisions and 
Changes Digest item 9 on page 66 . 

Definition 22: For each sequence s, if (i,a) £ s, then a is 
denoted by Si, s[i], or s(i). 

Definition 23 (Length of a sequence): For each finite se- 
quence s, 

1 . the number of elements of s is denoted by len(s) and 

2 . s is represented as (sq, Si, . . . , s n _j), where 
n = len(s). 

Definition 24 (Tuple): Vn £ N + , q is said to be an n-tuple 
if and only if q is a list of objects indexed by their position 
in the list, where the first element of the list has index value 


1 , the second element has index value 2 , etc., and the last has 
index value n. An ordered pair is a two-tuple. 

An alternative, and equivalent, representation for an n-tuple 
(91, 92, • • • , q n ) would be the sequence (s 0 , Si, . . . , s n _ 1 ), 
where V* £ {1,2,..., n}, Sj_i = < 7 ,;. It may also be noted 
that an element of a Cartesian product can be represented as 
a tuple. Thus, given n £ N, an n-tuple drawn from some 
set A is a member of the Cartesian product A". (See Revi- 
sions and Changes Digest item 10 on page 66 .) 


Definition 25 (Subsequence): The sequence t is said to be 
a subsequence of sequence s if and only if 3r C s, 3 a se- 
quence q £ r N 3 


1 . 


(i, (m,a)), (i + 1 , (n, 6 )) £ q 
(a) m < n and 


(b) 


3 (fc, c)£rBm<k<n 


and 


2. t = 


t = j(i, v ) : 3 (to, v) £ r 9 ( i , (to, v)) £ 9 j. 


Definition 26 (Set of Sequences of Members of a Set With- 
out Repeats): S* : p( fl) — > p(D N ) 9 

VQ £ p(fl), s £ S*(Q) -£=> s is a sequence 3 


1. (•, a) £ s => a £ Q and 

2 . (i, a), (j, a) £ s => i = j. 

For each set Q, the function S ' defines the set of all possible 
sequences of (not necessarily all) members of Q, without re- 
peats, i.e., if s £ S *(Q), then no member of Q appears twice 
in s. 


Definition 27 (Set of Sequences of Members of a Subset of 
a Set Allowing Repeats): S** : p(fl) — > p(fl N ) 3 
VQ £ p(D), s £ S **(Q) s is a sequence 3 
[(•, a) £ s => a £ Q\ . 

Definition 28 (Set of Sequences of All Members of a Finite 
Set Without Repeats): 

S : Cl F -► p{0 N ) 3 VQ £ s £ E(Q) o 
s is a sequence 3 

1 . len(s) = | Q | and 

2. a £ Q 3(*, a) £ s. 

For each finite set Q, the function E(Q) defines the set of the 
sequences of all of the members of Q. 

Definition 29 (Random member of a set): 
rndmember: D F — > 3 

VQ£D f ,3££S(Q)3 
mdmember((2) = £[rndint(0, \Q\ - !)]]• 

Given a finite set Q , rndmember((3) returns a random mem- 
ber of Q. 
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Definition 30 (Random subset of finite set): RND: N + x 

Dp — > Dp 9 

Q £ Dp, \Q\ > n £ N+ => 

RND(n,Q) = rndmember({A C Q: |A| = n}). 


Given a non-empty finite set Q and a positive integer n < 
\Q\. RND(n, Q) returns a random subset of Q whose cardi- 
nality is n. 


Aft contains a 4-tuple for each antenna in the communications 
support infrastructure. The elements of each 4-tuple identify 
the basic antenna attributes (the station where the antenna is 
located, the antenna’s ID, the antenna’s frequency band, and 
the antenna’s signal service capability). ,4 0 is supplied as in- 
put data to the scheduling system. 

Note: It is assumed that all SA antennas are able to sup- 
port S band. 


Definition 31 (Function to return the maximum value of a set 
of values): 

max: p(M) ->l3V closed set Q C R, £ Q 9 

1. y £ Q =>■ y < x 

2. max(Q) = x 

(See Revisions and Changes Digest item 1 1, page 66.) 

The function max returns the largest value in a set of nu- 
merical values. 

Definition 32 (Function to return the minimum value of a set 
of values): 

min: p(R) ->R9 V closed set Q C R, =te £ Q 9 

1. y £ Q => y > x 

2. min(Q) = x 

(See Revisions and Changes Digest item 12, page 66.) 

The function min returns the least value in a set of numer- 
ical values. 

Definition 33 (String): s is said to be a string if and only if 
s £ 2** ({a: : x is an ASCII character}) . 

Definition 34 (S): S = {s : s is a string}. 


4.3. Domain-Specific Definitions 


4.3.1. System Input Data 

Definition 35 (Set of network-station IDs): Sq = {s £ S : s 
represents the ID of a station in either the Space Network or 
the Ground Network} 

The string “TDRS-B” is an example of a station ID. So is 
supplied as input data to the scheduling system. 


Definition 36 (Set of antenna IDs): 

A* = {a £ S : a represents an antenna ID} 

A* is supplied as input data to the scheduling system. 


Definition 37 (Set of antenna-attribute tuples): ,4q C 
A* x {“S”,“K”,“K1”,“K2”} x (“MA”,“SA”}1 9 
a = (cii , . . . , d/C) £ Aq , (14 — MA cio — S 


So x 


Definition 38 (Function to return the number of SA antennas 
in service at a given station): Sq A : Sq — > N 9 s £ S}) =>• 

Sq A (s) = {a £ Aq : ai = s, 04 = “SA” } . 


Given station s, Sq(s) returns the number of SA antennas in 
service at station s. This information is computed from input 
data for the scheduling system. 


Definition 39 (Set of communications resource-outage inter- 
vals): O C £0 x A* x N 2 9 (01, . . . , 04) £ O => 

03 is a start time and 04 is an end time. 


O is the set of communications resource-outage intervals, 
each corresponding to times known in advance when data 
communications via prescribed antennas will be unavailable. 
O is supplied as input data to the scheduling system. 

Definition 40 (Set of user IDs): 

Uq = {zt £ S : u represents a user ID} 

A user (see definition of User on page 18) is any system ca- 
pable of communications via an antenna in NASA’s space 
data-communications infrastructure. Uq is supplied as input 
data to the scheduling system. 

Definition 41 (POCC Operation Periods): P: Uq — > p(Z). 

Given user u, P{u) is the set of time intervals during which 
the user’s Project Operations Control Center (POCC) is in 
operation. The intervals belonging to the set P(u) have start 
and end times specified as seconds of offset from some stan- 
dard epoch. If a POCC is always in operation, then there is 
only one interval specified, the start time of which is the start 
of the scheduling period and the end time of which is an ar- 
bitrary, sufficiently large number. P is supplied as input data 
to the scheduling system. 

Definition 42 (Set of all link IDs): 

L* = { x £ S: x represents a link ID} 

L* is provided as input data to the scheduling system 

Definition 43 (Set of all mission event types): M* = \x £ 
S : x represents a mission event type} 

M* is provided as input data to the scheduling sys- 
tem. An example of the set of mission event types would 
be: {“NIL”, “ORBIT”, “COMM- VIEW-PERIOD”, “IN- 
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VIEW”, “DAY-LIGHT”, “NIGHT”, “OVER-WATER”, 
“OVER-LAND”, “SUN-RISE”, “MOON-RISE”, “SUN- 
SET”, “MOON-SET”, “DAY”, “WEEK”, “MONTH”}. 
Some mission event types do not relate to a station in the sup- 
port infrastructure. For example, for the mission event type 
“MOON-SET”, a station ID is irrelevant, and so, for a mem- 
ber of M (see Definition 46, page 22) for that mission event 
type, the value of // 3 could be given as •. Mission event type 
“NIL” is reserved for cases where a user-support require- 
ment/request is specified in relation to an exact time interval 
(i.e., a “specific” requirement, as opposed to a “generic” re- 
quirement; see definition of User Requirement, page 18). 

COMM-VIEW-PERIODs are assumed to be intervals dur- 
ing which RF communications with a given user via a given 
network station are possible. COMM-VIEW-PERIODs are 
determined in advance (and are assumed herein to be pro- 
vided as input data), by considering all factors that affect 
communications performance, as computed, for example, by 
the NASA Communications Link Analysis and Simulation 
System (CLASS) [19] and the “Automated Conflict Resolu- 
tion System” and the “TDRS Look Angle System” [20]. It is 
assumed that, according to the mission plan, the spacecraft 
attitude will be adjusted and maintained as needed to enable 
the appropriate on-board antenna(s) to receive and/or radi- 
ate signals from/to the designated support antenna. 

Definition 44 (Users’ communications links information): 

L 0 CU 0 x L* x {“S”,“K”,“Kl”,“K2”}x 

{“MA”,“SA”} x {“FWD”,“RTN”} x {“RCP”,“LCP”}x 

N + 9 (Ai, . . . , A 7 ) £ L 0 => 

1 . A 4 indicates which type of signal service (Multiple Ac- 
cess or Single Access) is required, 

2 . A 5 indicates the direction of data flow, 

3. Xq indicates the signal polarization required, and 

4. A 7 represents a data rate in units of Kbps (i.e., 10 3 bits 
per second). 

Lq provides all relevant information about all users’ commu- 
nications links. The schedule-generation algorithm requires 
this information in order to find a schedule that will satisfy 
requests for communications services. Lq is supplied as in- 
put data to the scheduling system. 

Definition 45 (Maximum allowed return data rate): 
MAXALLOWEDRTNRATE is a fixed parameter, pro- 
vided as input data for a given scheduling scenario, ap- 
plicable to the entire data-communications support infras- 
tructure, defining the maximum allowed data rate (in units 
of Kbps) for all return-data communications links com- 
bined at any given instant. 

Definition 46 (Set of mission event instances): 

M C Uq x M* x S 0 x N 2 9 (pi , . . . , p 5 ) £ M => 


1 . p 4 is a start time 

2 . p$ is an end time. 


M, supplied as input data to the scheduling system, is the set 
of mission event instances. The preparation of M requires a 
computational resource such as CLASS. 


Definition 47 (Set of communications links for given user): 

L: Uq p(L 0 ) 9 L{u) = |a = (u, A2, . . . , A7) £ Lo| 

For a given user u, L(u ) is u’s set of communications links. 
The function L can be regarded as a table of data supplied as 
input to the scheduling system. 


Definition 48: V : S 0 x U 0 -> p(M) 9 

(s,u) £ So x U 0 , {pi, ■ ■ ■ ,P5) £ V(s,u) 
pi = u,p 2 = “COMM- VIEW-PERIOD”, p 3 = s 


The function V, given (s, u) £ So x Uq, returns the set of all 
communications view periods for station s and user u. V, ef- 
fectively a table of data, is supplied as input to the scheduling 
system. 


Definition 49 (Potential Interference Intervals): 

p(Z) 9 


I: Sq x Lq 


(s, s', A, A') £ S$ x Lie £ J(a, s', A, A') 
3(pi,...,p 5 ) £ U(s,Ai),3(/xi,...,// 5 ) £ U(s , ,A , 1 ) 9 


i- C c [pi,p 5 ] n [p' A ,p' 5 \ ± 0, 

2. [f £ £, links A and A' are active at time t via stations 
s and s', respectively] £9 link A suffers unacceptable 
degradation due to interference by link A', 

3. V/3 £ Z 9 £ C /?, 3t £ /3\£ 9 at time t, 

(a) links A and A' are active via stations s and s’, re- 
spectively, and 

(b) link A does not suffer unacceptable degradation 
due to interference by link A'. 


Potential interference intervals are supplied as input data by 
(for example) the NASA CLASS interference analysis sys- 
tem (IAS) (see Introduction, page 8 ). Note that CLASS can 
supply potential interference intervals for the cases where a 
user’s communications link would be degraded by RF energy 
from a non-specific source such as cellular-telephone signal 
emitters or other non NASA sources such as radars. In such 
cases, the interfering “link” would have a CLASS-supplied 
link ID and user ID. 


Definition 50 (Function to return NASA-assigned user prior- 
ity): 

4>o : Uq — > N 9 Vzt £ Uq,$o(u) is the NASA-assigned 
mission-priority value 9 

\u’ £ Uq , u 1 7 / u, and u' has lower priority than u\ =£* 
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$oK) < ®o(u). 

NASA-assigned mission priorities are supplied to the 
scheduling system as input data. 


Definition 51 (Normalized user priority mapping): 

$ : U 0 -3 R 9 


u £ Uo, m = max({i: 3u' £ Uo, x = 
4>(u) = o(it). 


<W)}) 


5 . r-, £ N is a mission-event skip factor specifying how 
many mission events of type n must be skipped be- 
tween consecutive instances of prototype events in the 
sequence 7-3, 

6. r% £ Z is seconds of offset of an instance of a proto- 
type event in the sequence 7-3 from the start (if = 
“START”), or end (if = “END”) of a mission event 
of type n. 


<f>, supplied as input data to the scheduling system, maps 
NASA-assigned mission priorities to the interval [ 0 , 1 ]. 

Definition 52 (Service): 

Y C L 0 x N 4 9 (A, s~ , s + , d~ , d + ) £ Y => 

1 . s~ and s+ represent, respectively, the minimum and 
maximum allowed start-time offset from some given 
reference time, and 

2. d~ and d + represent, respectively, the minimum and 
maximum allowed duration of the service. 


Y is the set of tuples (A, s ~ , s + , d~ , d + ) that specifies users’ 
services in terms of links, earliest and latest start-time off- 
sets, and minimum and maximum durations, and is supplied 
as input data to the scheduling system. 


Definition 53 (User-Prescribed Prototype Event List): 

C: U 0 - 


! (s*on) 


u £ Uo, k £ N + , k < len(C(u)), 
i £ N, i < len(C(M)[fc]), 


C{u)[k][i\ = (A, 




) => A £ L(u). 


p is said to be a prototype event if and only if 3 u £ Uo, 3 k £ 
N 3 (k,p) £ C(u). (See Revisions and Changes Digest 
item 13 , page 66.) 

C[u) is the user-rt prescribed list (sequence) of prototype 
communications events for user u. Every communications 
event scheduled by the algorithm for the given user u will 
match the values of some element of C(u), with leeway on 
the duration and the start-time offset relative to a given proto- 
type event start time. The mission-operations project for each 
user u supplies the list C(u) as input data to the scheduling 
system. 


Definition 54 (User Requirements): Rq is a set each element 
of which is an ordered 17 -tuple (r 1, . . . , rrj) 3 

1 . r 1 £ S represents a requirement ID, 

2 . T2 £ T'o is a string representing a user ID, 

3 . r3 is a subsequence of the sequence C[r 2), the list of 
prototype events prescribed by user r 2 , 

4. r 4 £ M* is a string representing a mission-event type 
for user r 2 . 


7 . r’j £ Z is seconds of offset of an instance of a proto- 
type event in the sequence r 3 from the start (if r 9 = 
“START”), or end (if rg = “END”) of a mission event 
of type 7*4, 

8. rg £ {“START”, “END”} indicates whether the start of 
a prototype event instance is relative to the start or end 
of an instance of a mission event of type 7-4, 

9 . rg £ {“START”, “END”} indicates whether the end of 
a prototype event instance is relative to the start or end 
of an instance of a mission event of type r4, 

10 . 7 "io £ N + represents the total volume of data desired 
to be returned from the user spacecraft in units of 10 3 
bits during any instance of a prototype event in the se- 
quence r3, 

11 . rn £ {“Y”, “N”} indicates whether the user’s POCC 
must be open during an instance of a prototype event 
in the sequence r 3 , where “N” means the POCC is not 
required to be open, 

12 . ri2 £ {“Y”, “N”} indicates whether mutual interfer- 
ence may be neglected in scheduling communications 
events, 

13 . ri3 £ N is the minimum allowed separation, in sec- 
onds, between any two consecutive instances of a pro- 
totype event in the sequence r 3 during any given com- 
munications event window as defined below, 

14 . 7"i4 £ N is the maximum allowed separation, in sec- 
onds, between any two consecutive prototype event in- 
stances, 

15 . ri5 £ N is the offset, in seconds, from the start of the 
scheduling period to the earliest time at which any in- 
stance of a prototype event in the sequence r 3 is allowed 
to start, 

16 . ri6 £ N is the offset, in seconds, from the start of the 
scheduling period to the latest time at which any in- 
stance of a prototype event in the sequence r3 is allowed 
to end, and 

17 . 7"i7 £ N is the nominal prototype-event start time off- 
set, in seconds, from the start of the scheduling period. 
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Ro, given as input data by the users, is a set each element 
of which is a user requirement. A requirement specifies ei- 
ther repeating or singleton (nonrepeating) communications 
events to satisfy the user’s needs for communications via sta- 
tions in the network. A requirement may specify (via param- 
eters ri3 through r 4 6, and via the last four parameters in each 
of the user’s defined services (see Definition 52 (page 23))) 
loose or tight tolerances on positioning of events in time. 

Example of a communications event window relative to 
the mission event type “SUNRISE”: Starting 20 sec before 
each third sunrise, ending 15 min after the sunrise. In this ex- 
ample, the mission-event skip-factor (r-p would be 2. 

For every requirement r = (r i, . . . , r 47 ) where the mis- 
sion event type is “NIL”, there is a mission-event instance 
p = {pi,.. ps) in M where p 2 = “NIL” and [y 4 , p 5 \ = 
[ri5,rie]- 

4.3.2. Scheduling-Algorithm-Specific Definitions 

Definition 55 (Service Instantiation): 

Y l : Y — > p(N x A 0 x N 2 ) 3 

Vy = ( A= (Ai, . . . , A 7 ), s _ , s + , d~,d + ) G Y, 

(t,a,s,d) G Y\y) <^> 

1. CL = (01,02,03 = A3, 04 = A 4 ) G Aq, 

2. s~ < s < s+, and 

3. dr < d < d + 

Y 1 returns, for each defined service y. the set of all pos- 
sible instantiations (t,a,s,d) of y where the link might 
be activated on the assigned antenna a during the interval 

[(t 4- s), (t 4- s -f d)]. 


Definition 56 (Function to return largest overlap of service 
with given view period): 

Y y :NxMx7-)29 

( \p y = {pj, ■ ■ -,pj), 
y = (A = (Ai, . . . , A 7 ), «-,«+,•, d + )) G 


N x M x Y 3 pX 


A 1: pV eV(pX,pX) 


Y Y {t , p v , y) = [pj, pj] n [(t + s ),(t + s+ + d+)] . 


Y y (t , p Y , y) is the largest interval during which the service y 
instantiation, relative to the given offset t from the start of the 
scheduling period, would overlap the given view period /i V . 
The interval Y Y (t, // v , y) covers any possible instantiation of 
y relative to the given view period p Y and the given offset t 
from the start of the scheduling period. 


Definition 57 (List of users): 

U : Rq -3- Uq 3 r = (tt, . . . , ri 7 ) G Ro =>■ U(r) = r 2 - 


U (r) represents the user for which r is a prescribed require- 
ment. 

Definition 58 (Time-ordered sequence of mission events for 
a given user requiring a given mission event type): 

M type : Rq -3 E*(M) 3 
Vr = (n, . . . ,r 17 ) G R 0 , 

M type (r) = e G E* (M) ^ 

1. [iGN,i< len(^)] => ^j[l] = r 2 an d 6: [2] = r 4 and 

2. [i,j G N ,i < j < Ien(^)] => 

[m,m] < few, ^[5]] 

(See Revisions and Changes Digest item 14, page 66.) 

Given r G Ro, M type (r) is the time-ordered sequence of 
all the members of M for user r 2 that have mission event 
type r 4 . 

Definition 59 (Function to return a start time or an end time 
for a given mission event): 

M t : {“START”, “END”} x M -3 N 3 
(x, p = {pi , . . . , p 5 )) G dom(Mx) => 


Mj(x, p) 


p A if x = “START” 
p 5 if x = “END” 


Mj returns a start time or an end time for a given mis- 
sion event. The returned time is the reference time relative 
to which a prototype event will be instantiated according to 

t*6* 


Definition 60 (Function to return the reference time for a 
given mission event): 
tref: R 0 x M > Z 3 
V(r = (n,...,n 7 ), 

T = (ph ■ ■■ 1 P5)) G Ro x M, 
tref(r, p) = t p <=> 


Pi = r 2 ,p 2 = r 4 , 


t 


p ~ 


15 

M T (r s ,p) +r 6 


if r 4 = “NIL” 
otherwise. 


(See Revisions and Changes Digest item 15, page 66.) 

tref(r, p) returns the reference time specified by require- 
ment r relative to any mission event p of type r 4 , with re- 
spect to which any prototype communications event would 
be scheduled, subject to the skip factor r.5 . 


Definition 61 (Function to return indexes to mission event in- 
stances determined the skip factor): 

Afskips : Rq x N — > a (N) 3 
V(r = (n, . . . ,ri 7 ),i) GK 0 xN, 

Mskipsfe i) = £ G S*(N) <^> 


1. i < r 5 , 
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2 . 

3. 


n = len(Mty P e(r)) =>■ 

len(£) = n — n mod (rs + 1) /(rs + 1), and 

[j G N, j < len(£)] => £[j] = j(r 5 + 1) + * 


M s ki ps (r, i) is the list of indexes into M t yp e (r) such that, start- 
ing with the mission event instance M type (r)[i], these ele- 
ments of M t yp e (r) correspond to the mission event instances 
determined by applying the skip factor 7-5. The concept (see 
Figure 3 (page 25)) of applying a skip factor having the value 
n entails the process of (1) starting with some given mission 
event instance, (2) ignoring (i.e., skipping) the next n mis- 
sion event instances, (3) keeping the next mission event in- 
stance, (4) skipping the next n mission event instances, etc. 
Note that in normal practice, the starting point for the pro- 
cess will be not some arbitrary member of M type (r), but in- 
stead will be Mtype(r) [0], i.e., the first mission-event instance 
of type r±. This practice satisfies the normal mission expec- 
tation that in maximizing the satisfaction of mission require- 
ments, no opportunities for enabling data communications 
will be foregone. 


Definition 62 (Function to return a given user’s POCC oper- 
ation period that has the largest intersection with a given in- 
terval): 


Tin ax : Ro xZ-)Z9 

(r,P) G Rq x Z,P max (r,/3) 


C G Z 




1. C e P(U(r)), 

2. g = £ (T P ^ 0, and 


3. 


r) G P(U(r)), h = 77 fl P => g + — g > h + — h 


P max (r, p) returns the POCC operation period for user U (r) 
that has the largest intersection with the given interval p. 


Definition 63 (Function to return the largest interval in the 
given view period during which a given service can be in- 
stantiated): 

y^ ax : Ro x N 2 x M 2 -4 N x A 0 x N 2 9 
V(r = (n,.. ,,r 17 ),k,n,p = (r 2 , r 4 , p 3 , Pi, P5), 

= (Ai, • ■ • , pj)) G dom(y^ ax ), 
y max(c n, p, p Y ) = ( t p , a, s, d) <G> 

1 . (t p , a = (ai, . . . , 04), s, d) G codomain(T^ ax ), 

2 . p y G V(ai,r 2 ), 

3 . t p = tref(r, p), 

4 . k < len(r 3 ), 

5 . n < len(r 3 [fc]), 

6. (t p ,a,s,d) G y I (r 3 [fc][n]), 

(01 = ay, o 2 = a 2 , a 3 , 04) G O => 

[o 3 , 04] n [(t p + s) , (t p + s + d)] = 0 , 


Instances of mission event of a 


type specified by parameter r 4 : 

•W\ ^ 


0 12 3 45 6 789 10 11 

. 


1 — indexes into Mt ype (r)' 

\ i I 

2 5 8 

Aftype(r) indexes listed in M s ki ps (r, 2) 
(with rs — 2) 


11 


Figure 3. An example illustrating the skip- 
factor concept. Twelve instances of a mission 
event of type r 4 are shown along the time line. 
These instances have indexes 0 through 11 in 
the sequence M t y pe (r). The relevant parameter 
values (see Definition 61 (page 24)) in this ex- 
ample are the skip factor, r 5 = 2, and the index, 
i = 2, of the first (i.e., the left-most) instance of 
a mission event of type r 4 where an instance of 
a prototype event is to be scheduled. Thus, af- 
ter skipping the next two instances of a mis- 
sion event of type r 4 , the next index in the 
list is A/ skips (r, 2)(1) = 5 . Note, however, that 
in normal practice, the starting point for this 
process will be not some arbitrary member of 
Myp e(r), but instead will be M t y pe (r)[0], i.e., the 
first mission-event instance of type r 4 , corre- 
sponding to setting the index i to 0. 



“NIL” ,[p4, p 5 \ 


[n5,rie], 


P = Y y (t p , p y ,r 3 [k][n])), p ^ 0, 
[r n =“N ”,V = P]W 


[rn = “Y” , C = Pnmx(r, P),T] = COP] 


V 


r 4 ^“NIL”,C = [t P ,pJ], 

P = (nT v (t p ,/i v ,r 3 [fc][n ])),/3 ± 0, 
[r n =“N ”,77 = / 3 ]V 


[ r ll = “Y” , C = Pmax(t", P), V = ( o P] 


9. t p + s = r) , d = r] + — (t p + s) > 0 

^m ax ( r > k,n, p, p y ) gives the largest interval in the given 
view period p y where, (a) with respect to [r 15 ,rig] (when 


7. 
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f4 = “NIL”) or (b) with respect to the given mission event p 
(when the given requirement specifies the start of the given 
prototype event in relation to the given mission event), the 
given service (stipulated by (r, k, n )) can be instantiated with 
an antenna assigned avoiding any resource outage. 


Definition 64 (Function to return the set of all possible in- 
stantiations of the given prototype event for a given mission 
event type with antenna assignments avoiding resource out- 
age intervals): 

C PRM : if x ij 0 x M p(S*(codomain(y 1 ))) 5 
[(k, r = (n, . . . , r 17 ),p =(pi=r2,fi2 = r 4 ,..., p 5 )) 
£ dom(C PRM ), 
p £ C^ M (k,r,fj,)] <^> 


1. k < len(r 3 ),len(p) = len(r 3 [A;]), 


2 . 



tref(r, p), n £ N, n < len(p) 


(a) 3(t p ,a,s,d) £Y 1 (r 3 [k][n}) 3 

p[n\ = ( t p ,a,s,d ), 

(b) 3 M V = (p*, . . . , £) e M> 3 [/, d *] e £, 

3 (tp, a , s*, cf ) = G Ti F V ) 9 

[s,(s + d)] C [s*,(s* + cf)] . 


C'o RM (A:, r, /x) is the set of all possible instantiations of the 
fcth prototype event in the list r 3 for the mission event p of 
type 7*4, with antenna assignments avoiding resource outage 
intervals. 


Definition 65 (Set of All Possible Schedules): 

0 C codomain (Cq RM ) 9 V0 £ 0, 

(k, r = (n, . . . , r 17 ), p = (m = r 2 , p 2 = U , . . . , /x 5 )) 
eNxHoxM, 


k < len(r 3 ), 
x £ C[ } RM (k 
x £ 9, and y £ 9 


x £ C RRM (k,r, p),y £ C^ RM (/c,r,/x), 


x = y 


0 is the set of all possible schedules. 

A schedule is a set of prototype-event instantiations, with 
no more than one such instantiation for each instance of the 
mission event type stipulated by each requirement. 

For each (k,r = (n, . . . , ri 7 ), p = (r 2 , r 4 , . . . , P5)) £ 
N x Rq x M, with k < len(ra), the scheduling objective 
is to schedule an instance of the prototype event r :i [k] so as 
to transmit a total quantity of data equal to rio x 10 3 bits, 
subject to 


Definition 66 (Function to return the degree to which a given 
schedule satisfies a given requirement’s skip factor): 
skipsat R " : 0 x R 0 — > R 9 

( 9,r = (n, . . . ,ri 7 )) £ 0 x R 0: 


n = len(M skips (r,0)), 

Q = |p: 3j, k £ N 9 j < n, k < len(r 3 ), 

)• 


p £ C 0 PRM (k, r, Mt y pe(r) M skips (r, 0) [j] 


P £ 0 } 


skipsat K '(0, r) = 


_ \ n /\Q\ 

[1000 


if \Q\ > 0 
if Q =0. 


(Note that the value 1000 is arbitrary, chosen to severely 
reduce the fitness score of 9 when the set Q is empty.) 


Given a schedule 9 and a requirement r, skipsat returns 
a value representing the ratio of the number of elements in 
M S ki ps (r, 0) to the number of prototype events scheduled for 
the members indexed by A/ sk i ps (r, 0 ). This final value will be 
exactly 1 if the skip factor requirement is satisfied (the pos- 
sibility that prototype event instances will be scheduled for 
other mission events is irrelevant for this metric), and will 
be a larger value otherwise. The assumption is that, from 
the start of the scheduling period, the first mission event of 
type r4 will have a mandatory first prototype-event instanti- 
ation, then 7-5 mission events of type will be skipped, and 
then the next mission event of type r4 will have a manda- 
tory prototype-event instantiation, with this pattern repeated 
for the remainder of the scheduling period. 

(See Revisions and Changes Digest item 16 , page 66, giving 
an equivalent but simpler formulation.) 


Definition 67 (Function to return the degree to which a given 
schedule satisfies the skip factor for all requirements): 
violations SKIP ’ i : 0 -x M 3 
9 £ 0 => violations SKIP *(0) = 

| Rq 1 skipsat R *(0, r) 

1~e.R0 

Given a schedule 9, violations SKIP returns the total of the 
metrics for all requirements as to how well their skip factors 
are satisfied — averaged over all requirements. For a perfect 
schedule, this metric will be exactly 1, and will be a larger 
value otherwise. 

Definition 68: skip FILI R : 0 x R () -£ R 9 

{9, r = (n, . . . ,ri 7 )) £ 0 x R 0 ,N = len(M type (r)), 


• the minimum and maximum communications-event h = len(Af type (r)) — len(Af sk j ps (r, 0 )), 

separations r 13 and r 14 and Q = {p: 3m,k £N,k < len(r 3 ), 

• the mission-event skip factor r 5 . m < len(M type (r)), ->m £ M skips (r, 0 ), 


26 


4.3 Domain-Specific Definitions 


4 DEFINITIONS 


p G Cj™ (k, r, Mtype(r) [m]) , p G 
skip FILLR *(0, r) = l + h~ 1 \Q\ 





T?|y y 

Given a schedule 9 and a requirement r, skip ' returns 
1 plus the ratio of | Q| (the number of prototype-event instan- 
tiations that are not required under the mission-event skip re- 
quirement 7"5 for mission events of type r4), to h (the number 
of mission event instances of type r4 that are required to be 
skipped). This metric has the value 1 if the schedule is perfect 
(i.e., there are no prototype events instantiated when not re- 
quired), and has a greater value otherwise. See the statement 
of the assumption under Definition 66. (Note that h = 0 cor- 
responds to an impossible condition, namely, that all of the 
instances of the mission event of type r4 are to be skipped.) 

Definition 69: violations SKIPF1LL : 0->N9 
9 G 0 => vioIations SKIPFILL *(0) = 

\Ro\~ 1 E skip FILL - R >,r) 

reRo 


Given a schedule 9, violations SKIPFILL returns the to- 
tal count, for all requirements r, of prototype-event instanti- 
ations that are not required under the mission event skip re- 
quirement 7-5 for mission events of type r4 — averaged over 
all requirements. 


Definition 70: start p : codomain (C PRM ) 


1. p G codomain (C PRM ) 

pGCftv), 


N 9 

3 (k, r, p) G N x f?o x M 9 


2. Q = {v: 3(f, •, s, •) G p 9 v = t + s} => 

start 1 ’)/)) = min(Q) 

Given the instantiation p of a prototype event, start 1 ’ (/;) re- 
turns the earliest start time of any service instantiation in the 


event. 


Definition 71: end p : codomain (C PRM ) ->N9 

1. p G codomain (C PRM ) => 3 (k,r, p) G N x R 0 x M 9 
p G C 0 PRM (fc,r, p). 


2 . 


Q = {u: 3(i, •, s, d) £pBv = t + s + d} 
end p (p) = max(Q) 


Given the instantiation p of a prototype event, end p (/;) re- 
turns the latest end time of any service instantiation in the 
event. 


Definition 72: minsepsat 1 ’ : 0 x R 0 — > N 9 

{9,r= (ri,...,nr)) G 0 x R 0 , 

Q = {{p,p') € 6 x 9: 3 (k,r,p) G N x R 0 x M 9 
P e C% RM (k,r,p), 

3 (k, r,p')£NxR 0 xM5p' G C£ RM (fc, r, p'), 

start 1 ’)//) > end p (p) 


start 1 ’)//) — end 1 ’)/;) < ri . j } 
minsepsat pJ ’(0, r) = \Q\ 


Given a schedule 9 and a requirement r, minsepsat p *(0, r) 
returns the total count of pairs of prototype-event instantia- 
tions for requirement r in schedule 9 that are separated by 
less than the minimum allowed separation ?’i3. 


Definition 73: maxsepsat 1 ’ : 0 x R 0 — > N 9 

(■ 9,r= (n, . . .,r 17 )) G0x4 

Q = {(p,p') € 9 x 9: 3 (k,r,p) G N x R 0 x M 9 
p g (7 PRM (fc, r, p), 

3 (As, r, p') G N x R 0 x M 9 p' G Cj RM (fc, r, p'\ 
start 1 ’ (//) > end p (p) 

-Bp" G 9 9 start p (p) < start p (p") < start p (p / ) 
start 1 ’ (//) — end 1 ’)/;) > r^} 
maxsepsat p *(0, r) = \Q\ 


Given a schedule 9 and a requirement r, maxsepsat 1 ’* (0, r) 
returns the total count of pairs of consecutive prototype-event 
instantiations for requirement r in schedule 9 that are sepa- 
rated by more than the maximum allowed separation 7-14. 

Definition 74: violations MINSFP : 0 — > R 9 
9 G 0 => violations M 1 N S F l “ ( 0 ) = 

1 + | Rq I 1 E minsepsat p *(0,r) 

r£R 0 


Given a schedule 9, violations MINSEP *(0) returns the value 1 
plus the ratio, averaged over all requirements r, of the num- 
ber of pairs of prototype-event instantiations for requirement 
r in schedule 9 that are separated by less than the minimum 
allowed separation ri 3 to the number of elements (prototype- 
event instantiations) in the schedule. This metric will be ex- 
actly 1 for a perfect schedule and a greater value otherwise. 

Definition 75: violations MAXSEP * :0->K9 
9 G 0 => violations M A x s F p * ) )) ) = 

1 + | Rq I 1 E maxsepsat p *(0, r) 

reRo 

Given a schedule 9, violations' 1 A X S E l>! ) 0 ) returns a value 
equal to 1 plus the ratio, averaged over all requirements r, 
of the number of pairs of prototype-event instantiations for 
requirement r in schedule 9 that are separated by more than 
the minimum allowed separation ri 4 to the number of ele- 
ments (prototype-event instantiations) in the schedule. This 
metric will be exactly 1 for a perfect schedule and a greater 
value otherwise. 


Definition 76: schedolpairs : 0 —x codomain(C PRM ) 2 9 

9 G 0 => 

schedolpairs (9) = \{p,p') G 9 x 9: 
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start 1 ’ (p) < start 1 * (p') < end p 



Given a schedule 9, schedolpairs(0) returns a set of overlap- 
ping pairs of members of 9 so that not both (p,p r ) and (p 1 ,p) 
belong to the set and (p, p) does not belong to the set. 


Definition 77: interf* : 0 -> R 9 Vfl S 0, 


Q = jz: r = (n,...,r 17 ), 

r' = (ri, . . . , r' 17 ) € R 0 , k , k' G N, 
p is an element of the sequence A/ tvpl .(r), 
p' is an element of the sequence M type (r'), 
k < len(> 3 ), k! < len(rg), 

V € C*™(k,r,p),p' G C*™(k',r’,p>), 

ip,p') G schedolpairs(Yi), 

n, n' G N, n < len(r 3 [fc]), n' < len(f3 W]), 

A = (r 2 , A 2 , . . . , A 7 ), A' = ( r' 2 , A 2 , . . . , A 7 ) G To> 
(A, = r 3 [/c][n], 

(A', 

p[n\ = (t, a = (ai, . . . , a 4 ), s, d), 
p'[™'] = {f,a' = 
e G /(ai, a'g, A, A'), 

e fl T s, t -f- s T dj n \t ! s f , t r -f- s' T ^ 0, 




interf*(0) = 1 + |0| 1 |Q| 


interf returns the value 1 plus an integer representing the in- 
stances where interference exists between two active links in 
a pair of prototype-event instantiations in the schedule, aver- 
aged over all elements (prototype-event instantiations) in the 
schedule. This metric will be exactly 1 for a perfect sched- 
ule and a greater value otherwise. 


Definition 78: endpts : 0 -9 p(N) 9 9 G 0 => 

endpts(6>) = jx: r = (n, . . . ,r i7 ) € i? 0 , 
k eN,k < len(r 3 ), 

(•,p) G M type (r), 

p G r, p),p G 9, (t, a , s, d ) G p , 

[a; = t-(-sVx = f + s + (i]| 

The function endpts(0) returns the set of all of the endpoints 
of all service instantiations in all prototype-event instantia- 
tions in schedule 9. 


Definition 79: endpts seq : 0 — > E* (N) 3 VO G 0. 

£ G endpts(0) seq <G> 

£ G S*(endpts(0)) and 

i G N, * + 1 < len(£) => £[i] < £[i + 1] 

The function endpts seq (0) converts the set endpts (Yl) into an 
increasing sequence of times on the timeline. 


Case 

At (a, c, d) 

(1) c =“SA” and d = • 

2 

(2) c =“MA” and d =“FWD” 

1 

(3) c =“MA” and d =“RTN” 

5 


Table 1. Space Network Forward and Re- 
turn Link constraints from the Space Network 
Users’ Guide (SNUG) 


Case 

At' (a, c, d) 

(1) c =“SA” and d = • 

4 

(2) c =“MA” and d =“FWD” 

2 

(3) c =“MA” and d =“RTN’ 

20 


Table 2. Ground Network Forward and Return 
Link constraints 


Definition 80: resourceusage : 0 x N — > 

p(N xR 0 xMxN 3 xL 0 x A 0 ) 9 


9 G 0,7 G N, 

i+ 1 < |endpts(0)|, 

(k,r = (n, . . . , rn), p) G N x R 0 x M, 
p G C$ RM {k,r,p),p G 9, 
n G N, n < len(r 3 [/c]), 
r 3 [k][n\ = (A = (r 2 , A 2 , ..., A 7 ), 

(f, a, s, d) G N x A 0 x N 2 , 
p[n\ = (t,a,s,d), 

C = [endpts scq (9) [i] , endpts scq (9)[i + 1]] , 


£ n [(t + s), (t + s y d)] ^ 0 =£■ 

(fc, r, p , 7i, C“,C + , A, a) G resourceusage($, i) 


Given a schedule 9 and an index i into the list of endpoints of 
all the service instantiations in 9 1 resourceusage (9, i) returns 
a set of 8-tuples containing values representing the resources 
used during the interval starting at the time endpts seq [*] . 

Definition 81: ac sn : {“S”,“K”,“K1”,“K2”}x 
{“MA”,“SA”} x {“FWD”,“RTN”} ->N9 
(b,c,d) G {“S”,“K”,“K1”,“K2”} x {“MA”,“SA”}x 
{“FWD”,“RTN”} => 

k sn (6, c, d) = 0, except as shown in Table 1 

ac sn returns the constraints on combinations of Space Net- 
work resource usage in any schedule. 

Table 1 states the station constraints that are provided as 
input to the scheduling system. For example, for any TDRS, 
there can be only one MAF, only five MAR, only two SSAF, 
only two SSAR, only two KSAF, and only two KSAR[19]. 
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Definition 82: 

k gn : {“S”,“K”,“K1”,“K2”} x {“MA”“SA”}x 

{“FWD”,“RTN”} 

(b,c,d) G {“S”,“K”,“K1”,“K2”} x {“MA”,“SA”}x 

{“FWD”,“RTN”} => 

k gn (&, c, d) = 0, except as shown in Table 2 

k gn returns the constraints on combinations of Ground Net- 
work resource usage in any schedule. 

Table 2 states the ground-terminal constraints that are pro- 
vided as input to the scheduling system. For example, for 
WSC (White Sands Complex), there can be only two MAF, 
only 20 MAR, only four SSAF, only four SSAR, only four 
KS AF, and only four KS AR. However, this is a simplification 
that would have to be dealt with, both in a more realistic for- 
mulation of the SN scheduling problem and in a full specifi- 
cation of the problem solution (i.e., as a schedule-generation 
algorithm to be implemented in a fielded, production-level 
scheduling system). The actual SA constraints are subject to 
additional rules that likewise would need to be included in 
the specification for a fielded scheduling system. For exam- 
ple, in the SNUG, Note 5 in Figure 3-1 “Telecommunications 
Services for each SGLT” [19] states the following: 

The SN can simultaneously support S-band and 
K-band (either Ku or Ka for TDRS spacecraft 
F8 through F10) forward and/or return services 
through one SA antenna to the same ephemeris. 


The function violations™^) DPTS (0, i, b, c, d) returns the 
count of violations of the constraints on usage of Space Net- 
work resource (6, c, d) in the interval i in schedule 6. 


Definition 84: violations 


GN-ENDPTS 

B-C-D 


0 x N x {“S”,“K”,“K1”,“K2”} x 

{“MA”,“SA”} x {“FWD”,“RTN”} -> N 3 

0 G 0, * G N, * + 1 < |endpts(0)|, 


(b,c,d) £ {“S”,“K”,“Kl”,“K2”}x 

{“MA”,“SA”} x {“FWD”,“RTN”}, 

Q=^x:x = A = (Ai,...,A 7 ),*) 

resource usage) (A i), 

A3 = 6, A4 = c, A5 = d, \, 


^gn = <2 - k gn (6, c, d) 


violations ^ • E , N D PTS ( # , 1 . b , c, d) = max({0, t.'gn } ) 


G 


The function vi<)lations[ i ((( l I : ) NDPTS ((/. 1 . b, c, d) returns the 
count of violations of the constraints on usage of Ground 
Network resource (6, c, d) in the interval i in sched- 
ule 6. 


Definition 85: violations SNENDPTS : 0 x N — > R. 9 

(9, i) G 0 x N, h = |endpts(0) 1 — 1 => 


violations SNENDPTS ( 0 , z) = 

E 

(6,c,d)£dom(tt SN ) 


h ~ 1 E violations!^™ 0 ™ (0,i,b,c, d) 


The present disclosure is based on a formulation of the 
NASA data-communications scheduling problem that does 
not embody the above distinction (or any other distinction) 
between TDRS spacecraft in the Space Network. Special 
cases and changes in infrastructure constraints are generally 
expected over time and must be reflected in timely updates to 
any operational scheduling system. In this sense, the present 
disclosure should therefore be considered to represent an ap- 
proach and a method that can be adapted to the actual data- 
communications scheduling problem. 


Definition 83: violations™^™ DP,S : 

0 x N x {“S”,“K”,“K1”,“K2”} x 

{“MA”,“SA”} x {“FWD”,“RTN”} ->N3 

0£0,i£N, i + l< |endpts(0)|, 

(b,c,d) G {“S”,“K”,“K1”,“K2”} x 

{“MA”,“SA”} x {“FWD”,“RTN”}, 

Q = jz: x = A = (Ai, . . - , A r ), •) £ 

resource usage (71, ■<), 

A 3 = b, A 4 = c, A 5 = d, | , 

^sn = |Q| - k sn (6,c, d ) => 

vioIations™c™ DPTS ( 0 , i. b, c, d) = max({ 0 , u S n}) 


The function violations™'™ DPTS (0, i) returns the count of 
violations of the constraints on usage of all Space Network 
resources in the interval i in schedule 9, averaged by the num- 
ber of elements in endptsf/l) less 1. 


Definition 86 : violations GN ‘™ DPTS : 0 x N 

(9,i) € 0 x N,h = |endpts(0) | — 1 

violations GN ™ DPTS (M) = 
h~ 1 E violations!7c.D NDPTS (^G^) c >^) 

(b,c,<2)£ dom(« GN ) 


violations GN ENDPTS (6 ) , i) returns the count of violations of 
the constraints on usage of all Ground Network resources in 
the interval i in schedule 9, averaged by the number of ele- 
ments in endpts(ff) less 1. 

Definition 87: violations SN : 0->l9 
9 G 0 => violations™ (0) = 

1 + H- 1 E violations™‘™ DPTS ( 0 , i) 

ie N 

i+l<|endpts(0)| 


violations™ (0) returns a value equal to 1 plus the count 
of violations of the constraints on usage of all Space Net- 
work resources in schedule 9, averaged over all elements 
(prototype-event instantiations) in the schedule. This metric 
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will be exactly 1 for a perfect schedule and a greater value 
otherwise. 

Definition 88: violations™ :0->R9 
0 € 0 => violations™ (0) = 

1+I0I” 1 £ violations ™ ENDPTS (0, i) 

i+l< |endpts(0)| 

violations™ (0) returns a value equal to 1 plus the count of 
violations of the constraints on usage of all Ground Net- 
work resources in schedule 0, averaged over all elements 
(prototype-event instantiations) in the schedule. This metric 
will be exactly 1 for a perfect schedule and a greater value 
otherwise. 


Definition 89: 

usage STATION " SA ' ENDPTS :0 xNxS o ->N 3 
(0,i,s)e0xNxSo,i + l< |endpts(0)|, 

Q = | a;: x = A = (Ai,...,A 7 ), 

a = (ai, . . . , 04)) e resourceusage(0, i), 
a\ = s, A 4 = a 4 = “SA”|J => 
usage STATIONSA ' ENDPTS (0, i,s) = |Q| 

Given a schedule 0, given an index i into the se- 
quence of endpoints in endpts seq (0), and given a sta- 
tion s, usage STATION " SA ' ENDPTS (0, i, s) returns the demand 
for SA antenna support on s. 


Definition 90: 

violations STATI ™- SA - ENDPTS : 0 x N x S 0 -3 0 3 

(0, i, s) £ 0 x N X So, 

usa = usage STATI ™' SA ENDPTS (0, i, s) - 5 0 SA (s)] =► 
violations STATI ™' SA ENDPTS (0, i, s) = max({0, u SA }) 

violations STATION ' SA ' ENDPTS (0, i, s ) returns the count of vio- 
lations of the constraints on usage of SA antennas on station 
s in the *th interval in schedule 0. 


Definition 91: violations SA ENDPrs : 0 x N — > R 3 

(0,i)e0xN,li = |endpts(0) | — 1 => 

violations SAENDPTS (0, ? ) = 

h-' £ violations STATIONSAENDPTS (0, i, s) 


violations SAENDPTS (0, i) returns the count of violations of 
the constraints on usage of SA antennas in the <th interval 
in schedule 0, averaged by the total number of elements in 
endpts(0) less 1. 

Definition 92: violations SA : 0 — > R 9 
0 S 0 => violations SA (0) = 


1 + I0P 1 £ violations SAENDPTS (0, *) 

ieN 

i+l<|endpts(0)| 

violations SA (0) returns a value equal to 1 plus the count 
of violations of the constraints on usage of SA antennas in 
schedule 0, averaged over all elements (prototype-event in- 
stantiations) in the schedule. This metric will be exactly 1 for 
a perfect schedule and a greater value otherwise. 

Definition 93: stnsw PEI : 0 x N x R 0 x M —> Z + 3 

V(0, k, r = (n, . . . , n 7 ), /i) € 0 x N x R 0 x M, 
if p e G PRM (fc, r, p), 
if p £ 0, and 

Q = jx : 3i, j G N, 3A £ L 0 3 
i,j < len {r 3 [k]),i^j, 
r 3[k][i\ = (A, 
f3 [k][j] = (A, 

p[i] = (t, a = (ai, . . . , a 4 ), s, d), 

P\j ] = (t, a 1 = (ai, . . . , a 4 ), s', d'), 
s + d < s', 
a i 7 ^ 

[to e N, m < len(r 3 [fc]), 

p[m] = (t, a* = (a*, . . . , a 4 ), s*, d*), 
r 3 [fc][m] = (A, •, •, •, •)] => s' < s*, and 

x = {i, j, A)|, then 
stnsw PEI (0, k, r, p) = |<3| 

stnsw PEI (0, k, r, p) returns the number of station switches 
that occur in the prototype-event instantiation p identified by 
(k, r, p) in schedule 0. 

In this disclosure, for the metric stnsw PEI , a station switch 
is said to occur if, for a prototype-event instantiation p iden- 
tified by [k,r = (ri, . . . , ri 7 ), p), there are two services 
r3[k][i] = (A, •,*,*,•) and r 3 [fc][j] = (A, • ,*,*,•), i,j e 
N,i,j < len(r 3 [fc]),i ^ j such that if p[i\ = ( t,a = 
(ai, . . . , a 4 ), s, d) and p[j] = (t,a' = (o' 1; . . . , a 4 ), s', d'), 
and s + d < s', then a 1 ^ a[ (i.e., the station providing 
the link service changes from the earlier service instantiation 
to the later), and if to £ N, to < len(r 3 [fc]), m ^ i,m ^ 
j,p[m] = ( t,a = (a\,...,a A ),s*,d*), and r 3 [fc][m] = 
(A, •, •, •, •), then s' < s*. Other possible definitions of “sta- 
tion switch’' may be substituted for the one given above or 
may be included as additional metrics. 

Definition 94: violations STNSW : 0 — > R 3 
0 e 0 => violations STNSW (0) = 

1 -0 1 0 1 1 £ stnsw PEI (0, k, r, p) 

r=(r 1 ,...,r 17 )GH 0 

fcGN9fc<len(rg) 

(•,^)€M type (r) 

violations STNSW (0) returns a value equal to 1 plus the num- 
ber of station switches that occur totaled for all prototype- 
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event instantiations in schedule 9, averaged over all elements 
(prototype-event instantiations) in the schedule. This metric 
will be exactly 1 for a perfect schedule and a greater value 
otherwise. 


Definition 95: rtndatarate COMBINED :0xN->N9 
(6, i) £ 0 x N, i + 1 < |endpts(0) | =>■ 


rtndatarate 


COMBINED 


E 


(M = 


a 7 


, A=(A^ , ■ • - , Ay) , •) £resourceusage(0 ,i) 


rtndatarate COMBINED (0, i) returns, for the interval indexed 
by i in schedule 9, the combined data rate in all the active 
“RTN” links. 


Definition 96: violation RTNRATE : 0 x N — > N 9 

(M £ 0 x N,z + 1 < j endpts(0) | , 

x = rtndatarate COMB1NED (0, i), 

[x > MAXALLOWEDRTNRATE => v = 

[x < MAXALLOWEDRTNRATE => v = 



violation RTNRATE (0, i) = v 


Given a schedule 9 and an index i into the sequence of 
endpoints in endpts seq (0), violation RTNRATE (0, T) returns the 
value 1 if the total of the data-rate values in all of the active 
“RTN” links during the interval in schedule 9 whose left end- 
point is indexed by i exceeds the value of the fixed parameter 
MAXALLOWEDRTNRATE, and returns 0 otherwise. 

Definition 97: violations RTNRATE : 0 — > M 9 

9 £ 0, ft = |endpts(0)| — 1 =>■ 
vioIations RTNRATE (0) = 

1 + h- 1 Y violation RTNRATE (0,i) 

i£N 

i+K |endpts(0) | 


violations RTNRATE (0) returns a value equal to 1 plus the 
number of intervals in schedule 9 in which a data-rate vio- 
lation exists, averaged over the total number of intervals in 
schedule 9. This metric will be exactly 1 for a perfect sched- 
ule and a greater value otherwise. 

Definition 98: satisfied PE1 : Q xN x R 0 x M — » M 9 

(0,k,r = {r\ , . . . , r i7 ) , p) £ 0 x N x R 0 x M, 


p £ Co BM (k, r , p),p £ 9, x £ K, 

Q = j(d, e) £ N 2 : n £ N, 

n < len(r 3 [fc], (•,•,•,£*) = p[n], 

(A = (Ai,...,A 7 ), •,*,*,•) =r 3 [k][n], 
A 5 = “RTN”,e = A 7 }, 


X = 


Y2 ed > 0 


(d,e)€Q 

satisfied™ 1 (#, k. r, p) = 1 


1 - x/r w 


satisfied™ 1 (0, k, r, p) returns the total data bits returned to 
the POCC during the prototype-event instantiation identified 
by ( k , r, p) in schedule 9, divided by the desired volume r 10 
of data returned in the instantiation of any prototype event 
scheduled to satisfy r. This metric will be exactly 1 when the 
total number of returned data bits equals the desired quan- 
tity, and will be a nonnegative number less than 1 otherwise. 

Definition 99: satisfied R : 0 x R 0 — > R 9 

(< 9,r= (r i, . . . ,n 7 )) G 0 x R 0 , 

Q = jp: 3 (k,p) GNxMs 
P 6 C£ RM (/c,r,p),p G 6>| 


h = max({l, |Q|}) 


satisfied R (if r) = 

hr 1 satisfied™ 1 (9,k,r,p) 


fe£N,fc<len(r3) 

(•.MjeMjypgCr) 


satisfied 1 * (0, r) returns, for requirement r, the ratio repre- 
senting the satisfaction of the requirement rio for total data 
bits returned by all the prototype-event instantiations for re- 
quirement r in schedule 9, averaged over all such prototype- 
event instantiations. The value returned is a nonnegative 
number not exceeding 1. The metric will have the value 1 
if the schedule is perfect. 

Definition 100: satisfied :0— >R90G0=i> 
satisfied* (9) = 2 — Jj $(C/(r))satisfied R (0,r) 

i"G-Ro 


satisfied ( 9 ) returns, for all requirements r, a value equal to 
2 minus the product of all of the user-priority-weighted ratios 
representing the satisfaction of the data-return requirements 
rio for total data bits returned to Earth by all the prototype- 
event instantiations for requirement r in schedule 9. This 
metric corresponds to the overall degree to which the sched- 
ule satisfies all data-return requirements. The value returned 
will be exactly 1 for a perfect schedule and a greater value 
otherwise. 


Definition 101: Vj G {0, . . . , 11}, Jj : 0 
violations STNSW (9), 
violations SKIP *(0), 
vioiations SKIPEILL * (9), 
violations MINSEP *(0), 
vioIations MAXSEP * (9), 
vioIations SN (0), 


9 9 G 0 


Jo(0) = 

H0) = 
HO) = 
HO) = 
J 4(0) = 
HO) = 
HO) = 
HO) = 
HO) = 
HO) = 
Jio(0) = 
Jn(0) = 


violations GN (0), 
violations'^ (Yl), 
violations STNSW (0), 
vioIations RTNRATE (<9), 
= interf*(0), and 
= satisfied* (9) 
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Definition 102: fitness :0->R9060=> 
fitness (9) = J j(6) 

3 6{0,...,11} 

This is the “fitness function”, which returns 1 for a perfect 
schedule and larger values for schedules that are not so good. 

Note the perhaps unexpected numerical aspect of the fit- 
ness function defined above, by which a better schedule has 
a lower numerical value than a worse schedule. The value of 
the metric is unity for a perfect schedule, or a larger value for 
a less-than-perfect schedule. 

We now define a series of functions that provide the 
genetic mutation and crossover transformations needed to 
evolve the working population during the operation of the 
schedule-generation algorithm (see Section 5 (page 35)). 


Definition 103: rndpei :0 — >N x R 0 x M B 

9 G 0, r = mdmember(i? 0 ), 
j = rndint ( 0 , len ( M type ( r ) ) ~l),p = M type (r)\j\, 
k = rndint ( 0, len (r 3 ) — 1), 

p e C^ilc, r,p),p g e 
rndpei(d) = (k,r,p) 


Given a schedule 0 . rndpei(0) returns a parameter tuple 
(k,r, p) that corresponds randomly to a prototype-event in- 
stantiation belonging to 9. This is a pseudo-function. 


Definition 104: rndsvc tO-jNxJJoxMxNs 
9 G 0, (k, r, p) = rndpei(0), 


n = rndint(0, len(r 3 [/c]) — 1) 
rndsvc(d) = ( k,r,p,n ) 


Given a schedule 0 . rndsvc(0) returns a parameter tu- 
ple (k, r, p, n) that corresponds randomly to a service in 
a prototype-event instantiation belonging to 9. This is a 
pseudo-function. 


longing to 9 (and identified by the tuple (k, r, p)) replaced 
with a service instantiation (f, a, s, d). 


Definition 106: slipsvc :0->03 
{9, k, r,p,n, t, a, s„ ew , d) G 

0 x N x Rq x M x N 2 x A 0 x N 2 , 

(k, r, p, n) = mdsvc(0), 
p G C'o RM ( fc > e 9,p[n] = ( t,a,s,d ), 

p Y € V(ai ,r 2 ), 

(s*, d*) G N 2 , 

(t, a, s* , d*) = Y^ ax (r, k, n, p, p Y ), and 
Snew = rndint(s*, (s* + d* — d)) => 
slipsvc(0) = modsvc(0, k, r, p, n, t, a , s new , d) 


Given a schedule 9 , slipsvc(0) returns a schedule identical to 
9 except with a randomly selected service instantiation in a 
prototype-event instantiation belonging to 9 replaced with a 
service instantiation resulting from slipping the original ser- 
vice instantiation to the left or right by an allowed random 
amount. This is a pseudo-function. 


Definition 107: chngsvcdur: 0 —X 0 9 

(9, k,r, p) G 0 x N x R 0 x M, 

(k, r, p , n ) = rndsvc(0), 
p G C£ RM (fc,r, / u),p G 9,p[n] = (t,a,s,d), 

e M, 

p Y G V(ai,r 2 ), 

(s*,d*) G N 2 , 

C t,a,s*,d *) = Ym ax (r, k, n, p, p Y ), 

(A, •, •, d~ ,d + ) G L 0 x N 4 , 
f 3 [k][n] = (A, •, •, d~,d + ), 

4a* = min({d*,d + }), and 

dm w = rndint(d _ , d max ) => 
chngsvcdur(0) = modsvc(0, k, r, p, n, t. a, s, d„ 


Definition 105: 

modsvc: 0xNxJloxMxN 2 x4oxN 2 ->03 
(i 9 , A;, r, p, n, t, a, s, d) G 

0 x N x R 0 x M x N 2 x A, x N 2 , 

(9' G 0, 

P € C£ RM (fc,r, / u),p G 9, 
p' eC™ M (k,r,p),p' e 9', 

9\{p} = 9'\{p'}, 

[j GN ,j < len (p),j ± n] => p[j\ = p'\j], and 


p'[n ] = (t, a , s, d) =4* 
modsvc(0, k, r, p, n, t, a , s, d) = 9' 


Given the tuple ( 9 , k, r, p, n, t, a , s, d), the function modsvc 
returns a schedule identical to 0 except with the service in- 
stantiation indexed by n in a prototype-event instantiation be- 


Given a schedule 6, chngsvcdur(0) returns a schedule iden- 
tical to 9 except with a randomly selected service instantia- 
tion in a prototype-event instantiation belonging to 9 replaced 
with a service instantiation resulting from changing the du- 
ration of the original service instantiation by an allowed ran- 
dom amount. This is a pseudo-function. 

Definition 108: chngsvcsta: 0 — > 0 9 

( 9 , k, r, p) G 0 x N x Rq x M, 

( k , r, p , n) = rndsvc(0), 
p £ c™M(k,r, p),p G 9,p[n\ = (t,a,s,d), 

£ G E(A 0 ),i = rndint(0, |A 0 | - 1), 
j G N, j < len(£), £\j] =a,i ± j, 
a' = £[i], a[ ^ 01,03 = o 3 , a' A = o 4 , 

/r v G V(oi,r 2 ), 
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(. s*,d *) g N 2 , 

(t, a', s* , d*) = Y^ ax (r, k, n, p, p Y ), and 
[( (t + s), (t + s + d)} C [(f + s ), (t + s + d )] 
chngsvcsta(0) = modsvc(0, k, r, p, n, t, a', s , d) 


Given a schedule 9, chngsvcsta(0) returns a schedule iden- 
tical to 9 except with a randomly selected service instantia- 
tion in a prototype-event instantiation belonging to 9 replaced 
with a service instantiation resulting from changing the sup- 
port antenna of the original service instantiation to a ran- 
domly selected allowed antenna on a different station. This 
is a pseudo-function. 


Definition 109: chngsvcant : 0 — > 0 9 

(■ 9 , k, r, p) G 0 x N x Rq x M, 

(k, r, p , n) = rndsvc(0), 
p £ C ( !| RM (fc,r, / u),p G 0,p[n] = {t,a,s,d), 

£ G S(^4 0 ),« = rndint(0, |A 0 | - 1), 
j G N, j < len(£), £[j] =a,i^ j, 

a ! = £[i], a \ = ai, 03 = 03, 04 = 04 => 
chngsvcant(0) = modsvc(0, fc, r, p, n, t, a', s, d) 


Given a schedule 9, chngsvcant(0) returns a schedule iden- 
tical to 9 except with a randomly selected service instanti- 
ation in a prototype-event instantiation belonging to 9 re- 
placed with a service instantiation resulting from changing 
the support antenna of the original service instantiation to a 
randomly selected allowed antenna on the same station. This 
is a pseudo-function. 


Definition 110: replacepei : 0->03 
(9, 9 ’ , k. k', r, p) G 0 2 x N 2 x Rq x M, 
( k,r,p ) = mdpei(0), 
k' = rndint(0,len(r 3 ) — 1 ),k' ^ k, 
p G C$ RM (k,r,p),p G 9, 
p’ £C RRM (k',r,p),p' G 9', 

9\{p} = 9'\{p'} 
replacepei (0) = 9' 


Given a schedule 9 1 replacepei(0) returns a schedule iden- 
tical to 9 except a randomly selected prototype-event in- 
stantiation belonging to 9 is replaced with an instantiation 
of a randomly selected different prototype event for the 
same requirement and for the same mission event relative to 
which the original prototype event was instantiated. This is a 
pseudo-function. 


Definition 111: cutexcesspei : 0->03 
(0, 9', k, k', r, p) G 0 2 x N 2 x R 0 x M, 
violation s SKIPFILL *(0) > 0, 

Q = |p: ( k,i,r,p ) G N 2 x R 0 x M, 


i <c len( A/type (r )), —*i G -T/skips(r, 0)> 

P = M type (r)[i],p G C RRM (k,r, p),p G 
cutexcesspei (9) — 9\Q 





Given a schedule 9, cutexcesspei (9) returns a schedule iden- 
tical to 9 except all excess prototype-event instantiations be- 
longing to 9 are excised. Excess prototype-event instantia- 
tions are those that cause the function vioIations SKIPFILL 
(see Definition 69) to return a value greater than 0. 


Definition 112: swappei: e 2 ->■ e 2 9 

(0, 0', e, e' , k, k' , r, p) G 0 4 x N 2 x R 0 x M, 

9^9', (k, r , p) = rndpei(0), 
k' = rndint(0, len(r 3 ) — 1), k! ^ k, 

p G C'o RM (*>GA0,P G 0, 

P ' £C RRM (k',r,p), P ' £9', 
e = 9\{p} U {p'}, 
e' = 0'\{p'} U {p}] =► 
swappei(0, 9') = (e, e') 


Given a pair (9,9') of schedules, swappei(0, 0') returns a 
pair (e, e') of schedules identical to (9,9') except a ran- 
domly selected prototype-event instantiation belonging to 0 
is swapped in 0' with an instantiation of a randomly selected 
different prototype event for the same requirement and for 
the same mission event relative to which the original proto- 
type event was instantiated. This is a pseudo-function. 


113: swappeionr: 0 2 — > 0 2 3 

,e')G0 4 ,0/0' 

member (Rq), 

: x G 9, (k, r, p) G N x Rq x M, 
G C R ™(k,r,p)} 


X G 


\ > > I / I 

G N X R 0 x M,x G C% RM (k,r,p), 
Co KM (k,r,p),x G Q,y G Q ^x = y, 
(k, r, p) G N x R 0 x M, 

£<PRM 

’0 x M, x G C PRM (fc,r, /r), 
l (k,r, p),x £ B,y £ B => x 


-'0 

: N x R, 

tPRM 

y 0 


Given a schedule pair (9, 9'), swappeionr returns a schedule 
pair (e, e') identical to (9, 9') except that for a randomly se- 
lected requirement r all prototype-event instantiations for r 
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belonging to 9 are swapped with all prototype-event instanti- 
ations for r belonging to 9' . 

Definition 114: swappeionu : 0 2 -9 0 2 3 

(0, 9' , e, e') £ 0 4 , 9 ^ O' , 

u = rndmember(t/ 0 ), 

Q = {x: (k, r = (n, . . .,n 7 ),p) £ N x R 0 x M, 

9 


r 2 = u,x £ Cq RM (/c, r, /z), a; £ 0 j 
(&, r,/i)eNxJJ 0 xM,ie r, p) 

PRM 


y £ Co (£;, r,p),x £ Q,y £ Q 


x = y, 


B = 


jx: (k,r = (n, . . . ,r 17 ),p ) £ N x f? 0 x M, 
r 2 = u,x £ Cq RM (A:, r, /z), x £ <?' j 9 


(fc, r, /i) £ N x l?o x M, x £ Co M (k, r, /z), 

y £C^ RM (k,r,p),x £ B,y £ B => x = y, 
e = (9\Q) U B, 
e' = ( 9'\B ) uqU 

swappeionu(0, 9') = (e, e') 

Given a schedule pair (0, 0'), swappeionu returns a sched- 
ule pair (e, e') identical to ( 0 , 0 ') except that for a randomly 
selected user u all prototype-event instantiations for u be- 
longing to 9 are swapped with all prototype-event instantia- 
tions for u belonging to 9' . (See Revisions and Changes Di- 
gest item 17, page 66 .) 


Definition 115: swapearlypeionr : 0 2 

(9, 9', e, e!) £ 0 4 ,6» ^ ff, 


0 2 9 


r = rndmember(i?o),len(M tyP e(r)) > 1, 
j = rndint(0,len(M type (r)) - 2), 

Q = jx : x £ 9, 

(i, k, r = (ri, . . . , r 17 ), p) £ N 2 x R 0 x M, 
i<j,P = M type (r)[i\,x £ Cj RM (fc, r, /z)| 9 

(k, r, p) £ N x R 0 x M,x £ C RRM {k,r,p), 


y £ Cg 1 (A:, r, p),x £ Q,y £ Q 


B = 


{x: 


x = y, 


x £ 


(z, k,r = (r i, . . . , ri 7 ), /z) £ N 2 x i? 0 x M, 
i<j,P = M type (r)[i\,x £ C RRM (k, r, /z)| 9 

(fc,r,/z) £ N x i? 0 x Af,x £ C£ RM (fc,r,/z), 

y £ C% RM (k,r,p),x £ B,y £ B =>x = y, 
e = (9\Q) U B, 
e' = {9'\B)UQ => 


swapearlypeionr (0, 9') = (e, e') 


Given a schedule pair (0, 0'), swapearlypeionr returns a 
schedule pair (e, e') identical to ( 0 , 0 ') except that for a ran- 
domly selected requirement r and a randomly selected mis- 
sion event instance p of type 7-4 all prototype-event instanti- 
ations for r not later than p belonging to 9 are swapped with 
all prototype-event instantiations for r not later than p be- 
longing to 9' . (See Revisions and Changes Digest item 18, 
page 66 .) 


Definition 116: swapmidpeionr : 0 2 — X 0 2 9 

{0,0',e,e') £ 0 4 , 9 ^ 9' , 

r = rndmember(i?o),len(M type (r)) > 2, 
i = rndint(0,len(M t ype(r)) — 3), 
j = rndint(i + l,len(M type (r)) - 2), 

Q = jx : x £ 9, 

( n,k,r = (ri, . . .,r 17 ),p) £ N 2 x R 0 x M, 
i<n<j,p = M type (r)[n], 

x £ Co RM (&, r, p) | 9 
(k, r, p) £ N x Rq x M,x £ C$ RM (k,r, p), 
y £ C RRM (k,r, p),x £ Q,y £ Q =>x = y, 
B = jx: x £ 9’, 

(n, k, r = (ri, . . . , r 17 ),p) £ N 2 x R 0 x M, 
i<n<j,p = M type (r)[n], 

x £ C RRM (fc, r, /z) j 9 

(k,r,p) £ N x R 0 x M, x £ (27 q RM (A;, r, /z), 

y £ C*o RM (fc, r, p),x £ B,y £ B => x = y, 
e = (9\Q) U B, 

e' = (9'\B) U Q => 

swapmidpeionr(0, O') = (e,e') 


Given a schedule pair (9, 9'), swapmidpeionr returns a 
schedule pair (e, e') identical to (9 1 9’) except that for a ran- 
domly selected requirement r and two randomly selected 
mission event instances p and p* of type r 4 all prototype- 
event instantiations for r inclusively between p and p“ 
belonging to 9 are swapped with all prototype-event in- 
stantiations for r inclusively between p and p* belong- 
ing to 9'. (See Revisions and Changes Digest item 19, 
page 67.) 


Definition 117: 

mdsvcs: N 2 x R 0 x M ► p(N x A 0 x N 2 ) 9 
V(n, k, r = (n, . . . , r 17 ), p = (/z ls . . . , p 5 )) £ 
N 2 x R 0 x M, 

(t p , a, s , d) £ rndsvcs (n, k, r, p) => 
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Pi = r 2 ,p 2 = r 4 , 
k < len(r 3 ),n < len(r 3 [fc]), 
t p = tref (r , p), 

(•,s 1 ,s 2 ,di,d 2 ) = r 3 [k\[n\, 

Q = | (i p , a,s’/)eHxi 0 xZxN: 

3p Y G M 3 

(t p , a, s* , d*) G Y^ lax (r,k,n,p,p ' v ) }, 

(ip, a, s', d') = rndmember(Q), 
if C = [s', (s' + d')] n [si, (s 2 + d 2 )], then 
s = rndint(C _ , (C + — di)), and 
if d m ax = min({d 2 , (C + - s)}), then 
d = mdint(di, dmax) 

Given (n, k, r, p), rndsvcs(n, k, r , /r) is a set of randomly se- 
lected service instantiations for service r 3 [fc][n] relative to 
mission event instantiation p. (See Revisions and Changes 
Digest item 20, page 67.) 

Definition 118: 

rndpeis: N x R 0 x M — > p(codomain(y 1 )) 3 
V(fc, r = (r lt . . . , r 17 ), p = (p 1 ,..., p 5 )) G 
N x i? 0 x M, 

£ G rndpeis(r, k, p) => 

Pi = r 2 ,P 2 = U,k < len(r 3 ), 

£ is a sequence having len(r 3 [fc]) elements, and 

[n G N, n < len(£)] => £[n] G rndsvcs(n, k, r, p) 

Given (k, r, p), rndpeis (k, r, p) is a set of randomly selected 
prototype-event instantiations for prototype event r 3 [k] rela- 
tive to mission event instantiation p. 

Definition 119: 

0RND : N+ -X p(0) 3 

Vn G N + , 3Q C 0 3 |Q| = n and 
6 G Q => Vp G 9, 

3(k,r = (n,...,r 17 ),p= (pi,...,p b )) G 
N x Rq x M 3 
Pi = r 2 ,p 2 = r 4 , 
k — mdint(0,len(r 3 ) — 1), and 
3* G N 3 

i < len (Mtype(r)) 3 
p = M type (r) [M skips (r,0)[i]], and 
P e rndpeis (fc, r, //), 
and 0RND(n) = Q 

0rnd(?t-) returns a set of n randomly generated schedules. 

5. Optimal Schedule-Generation 
Algorithm 

The definitions given in Section 4 permit a precise specifi- 
cation of an algorithm for generating optimal solutions for 


the NASA space-data communications scheduling problem. 
These definitions encompass functions for generating ran- 
dom permissible solutions, creating mutations of members 
of the working population, creating children of pairs of mem- 
bers of the working population using the “genetic crossover” 
mechanism, and evaluating the fitness of members of the 
working population. There are many, a very great many, dif- 
ferent allowable variants on these functions and therefore a 
very great many different variants on the algorithm to be 
specified below. These functions could be replaced or aug- 
mented with other allowable functions that reflect more so- 
phisticated genetic mutation and crossover mechanisms in- 
cluding, in particular, additional safeguards against possible 
premature convergence as discussed in the literature on ge- 
netic algorithms. Such refinements are potentially limitless 
and are beyond the scope of this disclosure. (See Revisions 
and Changes Digest item 21, page 67.) 

5.1. Specification of Optimal 

Schedule-Generation Algorithm 

Algorithm 1 (Optimal-Schedule Generation Algorithm): 

1. Assume given: 

(a) v G N + is the run time limit in units of seconds. 

(b) no G N + is the nominal working size of the pop- 
ulation at the beginning of each iteration of the 
algorithm. 

(c) II = 0R\r)(r<o), the initial, randomly selected 
population of schedules. 

(d) ip G N + , the number of steps in which new mem- 
bers of the population are generated in each iter- 
ation of the algorithm, i.e., the number of steps 
starting with step 4 and ending with step 15. 

(e) a G N 1 ^, a tuple having ip elements 3 

i. Vj G {1, . . . , ip}, aj G N is the number of 
new candidate members to be added to the 
schedule population in step j + 4 in the al- 
gorithm. 

ii. J2 a i ~ n o- 
j e{i,...,i/q 

The sequence a consists of the values of the 
internal parameters of the algorithm. 

(f) 0 < r G M, a small value to represent a policy 
or judgment as to how close to perfect a sched- 
ule must be to be considered “good enough” to 
exit the algorithm, r normally would be set small 
enough to ensure that the algorithm always ran 
for the maximum allowed run time v. 
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2. Let II' = 0. In each iteration of the algorithm, IT will 
accumulate members to be added to the present popu- 
lation, from which combination the no best schedules 
will be extracted to compose the next generation. 

3. W £ II, let 7 r' = cutexcesspei(7r) and let II = 

(n\W)u{/}. 

4. \/j £ {1, . . . randomly form IVj C II 9 II ? | = 

Otj. 

5. V7r £ III, let 7r' = slipsvc(7r), and let II' = II' U {V}. 

slipsvc (Definition 106) provides a “mutation’' 
mechanism, where parts of an “organism’s” “genome” 
are modified to produce an offspring, which is then in- 
corporated into II'. 

6. W £ II2, let 7r' = chngsvcdur(7r), and let II' = II' U 

Wb 

chngsvcdur (Definition 107) provides a “mutation” 
mechanism, where parts of an “organism’s” “genome” 
are modified to produce an offspring, which is then in- 
corporated into II'. 

7. V7T £ II3, let 7r' = chngsvcsta(7r), and let II' = II' U 

Wb 

chngsvcsta (Definition 108) provides a “mutation” 
mechanism, where parts of an “organism’s” “genome” 
are modified to produce an offspring, which is then in- 
corporated into II'. 

8. W £ II4, let 7 t' = chngsvcant(7r), and let II' = II' U 

Wb 

chngsvcant (Definition 109) provides a “mutation” 
mechanism, where parts of an “organism’s” “genome” 
are modified to produce an offspring, which is then in- 
corporated into II'. 

9. W £ II5, let 7 r' = replacepei(7r), and let II' = II' U 

Wb 

replacepei (Definition 110) provides a “mutation” 
mechanism, where parts of an “organism’s” “genome” 
are modified to produce an offspring, which is then in- 
corporated into IT. 

10. Let Q = RND(4«6) Fig) 9 (tt, 0) £ Q => -.(0,7r) £ 
Q. V(7t,0) £ Q, let (7 r',0') = swappei(7r, 9) and let 
IT =n / U {tt', 6»'}. 

swappei (Definition 112) provides a “crossover” 
mechanism, where the “parents” (7 r, 0) produce “off- 
spring” (n', 9'), parts of whose “genome” are from dif- 
ferent parents. Since two new solutions are added for 
each member of Q, a total of cts new solutions will be 
added. Similarly for each of the subsequent crossover 
steps below. 


11. Let Q = RND(ia 7 ,n?) 9 (tt, 9) £ Q => -.(0,7t) £ 
Q. V(7r, 9) £ Q, let (7 t',0') = swappeionr(7r, 9), and 
let IT = IT U{7r',0'}. 

swappeionr (Definition 113) provides a “crossover” 
mechanism, where the “parents” (tt, 9) produce “off- 
spring” (V, 9'), parts of whose “genome” are from dif- 
ferent parents. 

12. Let Q = RND(ia 8 ,II§) 9 (tt, 9) £ Q => -.(0,7r) £ 
Q. V(7r, 0) £ Q, let (tt',9 1 ) = swappeionu(7r, 0), and 
let IT = IT G{tv',6'}. 

swappeionu (Definition 1 14) provides a “crossover” 
mechanism, where the “parents” (7 r, 0) produce “off- 
spring” (7 r', 0'), parts of whose “genome” are from dif- 
ferent parents. 

13. Let Q = RND(ia 9 ,n|) 9 (tt, 0) £ Q => -.(0, tt) £ 
Q. V(7 r, 0) £ Q, let 7r',0' = swapearlypeionr(7r, 0), 
and let n' = IT U {7 r',0'}. 

swapearlypeionr (Definition 115) provides a 
“crossover” mechanism, where the “parents” (n,9) 
produce “offspring” (7 r',0'), parts of whose “genome” 
are from different parents. 

14. Let Q = RND(|ai 0 , n? 0 ) 9 (tt, 0) £ Q => -.(0, 7 r) £ 
Q. V(tt, 9) £ Q, let (7 r',0') = swapmidpeionr(7r, 0), 
and let II' = n' U {7 r',0'}. 

swapmidpeionr (Definition 116) provides a 
“crossover” mechanism, where the “parents” (n, 9) 
produce “offspring” (7 r',0'), parts of whose “genome” 
are from different parents. 

15. Let IF = 0 rnd(o!ii). Let IT = IT U IF. 

This adds to the population at most an new mem- 
bers randomly selected from 0. 

16. Find 11^ C II U IT 9 |ll^| = no and [7 iq £ n^,7r 2 £ 
(II U n')\nt] => fitness(7Ti) < fitness(7r 2 ). Set II = 
nt and set II' = 0. 

17. Find 7r 1 £ll9CGlI=> fitness(C) > fitness(7r!). 7 n 
is the best member of II. If fitness(7Ti) < 1 + r or run 
time exceeds the limit v, go to step 18; otherwise, go to 
step 4. 

18. Output the best schedule tv in II and exit. 

5.2. Schedule-Generation Algorithm: Internal 
Parameters 

Every successive generation of the population of schedules 
retains the best members of the previous generation com- 
bined with the new members added in the course of running 
the algorithm. The best member of a generation will be at 
least as fit as any member of the preceding generation, and 
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consequently the fitness of the best member of each genera- 
tion will be a monotonic function of processing time (or the 
iteration count) (see Appendix A (page 44)). 

The algorithm as specified in the previous subsection does 
not stipulate the values of the internal parameters (repre- 
sented by the tuple a), and is silent on exactly how they 
should be chosen. There is no obvious relationship between 
the values selected and the performance that should be ex- 
pected of an implementation of the algorithm, although a 
method of finding a performance-optimizing set of choices 
for those values would be, potentially, highly advantageous. 

While any reasonable choices of the values of the above 
internal parameters would not prevent an implementation of 
the algorithm from reaching an optimal schedule for a given 
scheduling scenario, other choices might improve perfor- 
mance. In theory, while keeping constant (a) the seeds for 
the random-number generator, (b) the run time, and (c) the 
computing resources between runs, runs of the algorithm us- 
ing different choices of the values of the internal parameters 
may not find solutions with the same fitness; that is, some 
of the choices may be significantly more effective in find- 
ing optimal solutions with better fitness scores. It should be 
noted that these internal parameters (as represented by the tu- 
ple a) are not the only internal parameters that might be de- 
fined. For example, in the mutation steps 5 through 9, the 
number of places in the individuals’ genome that are modi- 
fied to produce new individuals could be adjusted to reveal 
the effect on the algorithm performance. 

If, for a given representative scheduling scenario, experi- 
mental runs of the implementation using a variety of choices 
for the internal-parameter values revealed a significant per- 
formance advantage for a particular choice, it would be valid, 
absent any further insight or data, to use that choice when 
running the implementation for other scheduling scenarios. 
The idea would be that a random or uninformed choice of the 
values is not likely to be better than a choice that has been 
found to be, for some representative scheduling scenario, the 
best one of a set of tested alternatives. 

Section 6 will specify an algorithm by which, for any 
given scheduling scenario, an optimal choice of the values for 
the internal parameters may be found, assuming such an op- 
timum exists (where “optimum” is again used in the sense in- 
dicated in Section 2.4.7 on page 15). The optimal choice, for 
any given scheduling scenario, would be one for which the 
algorithm’s performance could not be improved by means of 
a different choice, and the problem of finding such an opti- 
mum will hereinafter be referred to as the S' problem. 

In Section 7, we will propose an answer to the question 
of whether there is any reasonable way of relating schedul- 
ing scenarios to each other, where a “small” difference be- 
tween two scheduling scenarios would mean a correspond- 
ingly small difference in the optimal choice of the values 


for the internal parameters. We will seek to identify a solu- 
tion space for what we hereinafter call the S^ problem — the 
final abstraction of the overall space data-communications 
scheduling problem — in which, for the implementation of 
the schedule-generation algorithm specified in Section 5.1, 
there exists an automated way to preprocess a given schedul- 
ing scenario to identify an optimal choice of the internal- 
parameter values. The remaining question of whether the per- 
formance of the overall system will be sensitive to differences 
in the choice of the values of the internal parameters will be 
left to future work — likely entailing considerable computa- 
tional effort rather than theoretical analysis. 

6. Internal-Parameter Optimization: 
The Problem 

We will now take up the problem — which in the previous sec- 
tion was designated the S' problem — of finding an optimal 
choice of the values of the schedule-generation algorithm’s 
internal parameters for a given scheduling scenario, thereby 
to optimize the schedule-generation algorithm for solving 
that scheduling scenario. 

6.1. The S # Problem: Introduction 

The internal parameter-optimization algorithm to be speci- 
fied in Section 6.3 will employ the same probabilistic search 
concepts presented in Section 5 in specifying the schedule- 
generation algorithm. As before, a population of solutions of 
the optimization problem will be evolved iteratively, and on 
each iteration the fitness of each member of the population 
will be determined. Not all, but just the fittest members of 
each generation, will be allowed to survive into the next gen- 
eration. 

By definition, each member of the population is not a 
schedule (as in the schedule-generation algorithm itself), 
but rather a choice, e, of values of the internal parameters 
of the schedule-generation algorithm, and choice e will re- 
main fixed until the schedule-generation application program 
produces the best possible (optimal) schedule for the given 
scheduling scenario 7 . The fitness of each member of the 
evolving population of such choices e would be a numerical 
value representing the performance of the system. By defini- 
tion, the performance of the system (given the choice e) will 
be the fitness score of the best schedule that can be produced 
by the schedule-generation algorithm in a prescribed amount 
of processing time, with prescribed computing resources. 

During the entire iterative process of finding the best so- 
lution (i.e., the best choice of the values of the internal pa- 
rameters of the schedule-generation algorithm), the schedul- 
ing scenario will remain fixed, and at the end of the iterative 
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process, the choice of the internal parameter values that re- 
sulted in the best performance is considered to be optimal. 

This abstracted search problem — the S* problem — will 
also have its own internal parameters, one of which is the pre- 
scribed amount of processing time allowed for the above it- 
erative process to produce a solution. Additional internal pa- 
rameters will be described below. While a subsidiary problem 
could be defined for the optimization of these parameters, it 
will be seen that this subsidiary problem would also have its 
own internal parameters to be optimized, leading to a sub- 
subsidiary problem of optimizing these internal parameters, 
and so on, without end — a kind of infinite regression. In the 
case of the NASA scheduling domain, it seems reasonable to 
ignore these subsidiary problems of optimizing internal pa- 
rameters of optimization problems, and instead, just make ju- 
dicious choices for the values of the internal parameters for 
the problem at hand (i.e., the S' problem), in the full expec- 
tation that the only disadvantage of doing so is that, to reach 
a solution that has the same fitness, processing time might be 
greater than it would have been with optimization. This posi- 
tion is further justifiable on the grounds that a one-time effort 
solving the S** problem, as proposed in Section 7, can obvi- 
ate the need to pursue indefinitely a chain of S*-problem op- 
timizations using the above iterative process. 

6.2. The S* Problem: Definitions 

Definition 120 (Set of All Scheduling Scenarios): 

r = | 7 : 7 = (L# C L 0 , O* CO,J<C /, 

P# C P, Apt C M, pit C p 0 ) | 9 

7 = (Pi*, 0#, I#, Pi*, M#, Pit) G T=> 

1. (n, . . . , ri 7 ) G Pit, k G N, k < len(r 3 ), 

iGN,!< len(r3[fc]) =4> 
r 3[k][i\ = (A, •) =>Ag 

2 . (Ai, . . . , A7) G P* => 3(7*1, ■ • • ) 7*17) G P^ 9 Ai = 7*2, 

3. (ai 1; ... , Ms) G Mii => 3 (n, . . . , 7 * 17 ) G Pit 9 

Mi = r 2 , 

4. ((s, s' , A, A'), •) G /* <^> 

3(mg ■ • • ,Ms) £ V(s, Ai), 

3(Mi,---,/4) G VXs'.A'i), 

3(n, . . . , 7 * 17 ) G RK and 

3(rj,...,rj 7 ) GP»9 

Al = 7*2, A'i = 7*2, 

Ml = 7*2, Ml = 7*2 

5 . (it, •) G Pi* =>• 3(7*1, • • • , 7*17) G pit 9 u = 7*2 

Definition 121: fitness* : T x x N + — >• K 9 

( 7 , e, t) G T x # x N + => 

1 . t is the run time allowed in units of seconds 


2 . fitness* ( 7 , e, t) = fitness(tr) is the fitness score of the 
best schedule, er, produced by the schedule-generation 
algorithm running on the prescribed computing re- 
sources during a run interval of length equal to t sec- 
onds, for the scheduling scenario 7 and the choice e of 
the values of the internal parameters. 

See Definition 102 (page 32) for the definition of the func- 
tion fitness. 7 p, recall, is the number of internal parameters of 
the schedule-generation algorithm (see Algorithm 1, steps Id 
and le (page 35)). fitness* is the “fitness function” for the 
S* problem, which returns 1 for a perfect choice of the val- 
ues of the internal parameters of the schedule-generation al- 
gorithm and larger values for choices that are not so good. 

6.3. Algorithm for Solving the S* Problem 

(See Revisions and Changes Digest item 22 on page 67.) 
Algorithm 2 (S* Algorithm): 

1 . Assume given: 

(a) 7 G T, a scheduling scenario. 

(b) v G N + , representing the allowed run time for the 
schedule-generation algorithm whenever it is ex- 
ecuted in the following steps. 

(c) ji* G N + , representing the allowed run time for 
performing iterations of the following steps in the 
search for the optimal choice of the values of the 
internal parameters of the schedule-generation al- 
gorithm. 

(d) 1 p G N + , the number of steps in which new mem- 
bers of the population are generated in each iter- 
ation of the algorithm, i.e., the number of steps 
starting with step 3 and ending with step 7. 

(e) a G N’*’ 9 Vj G { 1 , . . . , ip}, a :1 is the number of 
new candidate members to be added to the popu- 
lation in step j + 2 in the algorithm. Let 

n o = y^. a j 

be the nominal working size of the population on 
each iteration of the algorithm. 

(f) ADDSLIMIT* G N+. This is the limit on the 
number of new members of the population that 
can be added to the population in any algorithm 
step. 

(g) n = RND(7i 0 ,N^) 9 0 G n => 

Vj G {1, . . . , ip}, 0\j] < ADDSLIMIT*. 
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2 . 


3. 

4. 


5. 


6 . 


7. 


Let II' = 0. In each iteration of the algorithm, IT will 
accumulate members to be added to the present popula- 
tion, from which combination the n 0 best members will 
be extracted to compose the next generation. 

Vj E {1, . . . , ip}, randomly form 

n, c n 9 |iij | = ccj. 

Let Q C III 3 \Q\ = ot±. 


Find nt cnun '3 

Int I = n 0 and [tt elites (nun')\nt 


fitness* (7, 7 r, v) < fitness* (7, 9 , v). 

Let n = nt and IT = 0. 


9. Find 7rGn3(sn=> 

fitness* (7, v) > fitness* (7, 7r, v). 
7 r is the best member of n. 


Vtt g Q, 

(a) let 7r' = 7 r, 

(b) let j = rndint({l, . . . , ip}), 

(c) let 7T ’[j] = rndint({l, . . . , ADDSLIMIT*}), 

(d) let IT = n'U{7r'}. 

This is a “mutation” mechanism, where one element of 
an “organism’s” “genome” is modified to produce an 
offspring, which is then incorporated into IT. 

Let Q = RND(|a 2 , n|) 9 
(77 9) £ Q =4> -i(0, 7r) € Q. 

V(t t,0) € Q, 

(a) let n = rndint({l, . . . , ip}), 

(b) let 7r' = (n[l\,...,Tr[n\,0[n + l],...,0[ip]), 

(c) let 9’ = (#[1], . . . , 9[n], 7r[n + 1], . . . , 7r[t/>]), and 

(d) letn' = IT U{tt',9'}. 

This is a “crossover” mechanism, where ran- 
domly many of the first elements of one “organism’s” 
“genome” are swapped with the same elements in an- 
other, resulting in two new members, which are then 
incorporated into II'. 

Let Q = RND(|a 3 , II§) 9 
(77 9) £ Q =7* -i(0, 7r) € Q. 

V(t r,0) € Q, 

(a) let ni,n 2 = mdint({l, . . . ,ip}), n\ ± n 2 , 

(b) let 7r' = (7r[l],...,7r[m], 

9[ni + 1], . . . ,0[n 2 ],7r[ra 2 + 1], . . . ,7 r[^]), 

(c) let 9' = (9[l],...,9[m], 

7r[m + 1], .. . ,7T [n 2 ),0[n 2 + 1], ■ ■ -,9[ip]), 

(d) and let n' = n' U {it', 9'}. 

This is a “crossover” mechanism, where a random 
section of one “organism’s” “genome” is swapped with 
the same elements in another, resulting in two new 
members, which are then incorporated into II'. 

Let Q C # 9 e Q o 

V? S {1, . . .,ip},0\j] < ADDSLIMIT*. 

Letn' = JI'U RNDfo:..], Q). 

This adds a.\ new members to the population ran- 
domly selected from . 


10. If run-time exceeds 77*, output the best member 7r in II 
and exit; otherwise, go to step 3. 

6.4. The S* Problem: Discussion 

As in the case of the schedule-generation algorithm itself, the 
population of solutions in the S* algorithm evolve (through 
the iterative steps of evolutionary search) with a monotonic 
improvement of the fitness score of the best member of the 
population toward some evidently limiting value. After some 
elapsed processing time, the run must be terminated and if 
the “knee” of the curve that represents the fitness of the 
best member of the population at the end of each iteration 
of the algorithm has been passed (see analysis Section 10.2 
(page 44)), then the best solution produced to that point is 
considered to be the optimal solution of the S* problem. 

The question might arise whether the evolving population 
of solutions might enter a runaway progression of the magni- 
tude of the values of the internal parameters in the execution 
of the above algorithm. It is quickly seen that this is not a con- 
cern: recall that each of the schedule-generation algorithm’s 
internal parameters represents the number of new schedules 
that will be allowed to be added to the population in some 
given step in each iteration of the algorithm. If a choice, e, 
of the values of the internal parameters included a very large 
value, the fitness of the best schedule produced within the 
schedule-generation algorithm’s run-time limit, v (a given in 
the S* algorithm), would be so bad that e likely would not be 
a member of the next generation. 

While no experimentation has been conducted to test it, 
the working hypothesis is that a diminishing return would re- 
sult from unbounded increases in the magnitude of any one 
of the internal parameters, other factors being constant. Ac- 
cording to this hypothesis, the performance achieved by the 
schedule-generation algorithm could be graphed as a func- 
tion of the value of an arbitrarily chosen one of the schedule- 
generation algorithm’s internal parameters, keeping other pa- 
rameters constant. This graph would have a point to the right 
of which the performance would worsen monotonic ally. The 
left-most such point could be found through applying the 
approaches described herein, but it could only be regarded 
as pseudo optimal since it would differ from the optimal 
solution that would be found when the other internal pa- 
rameters were unconstrained as well. Further analysis based 
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on a model of the performance of the schedule-generation 
algorithm will be undertaken in Appendix A (Section 10 
(page 44)). 

7. A Further Abstraction: The S tt: 
Problem 

7.1. The S s# Problem: Introduction 

To maximize the practicality of the technology disclosed 
herein, we now consider the S :: problem (described briefly 
at the end of Section 5) — i.e., the problem of estimating an 
optimal choice of the values of the schedule-generation al- 
gorithm’s internal parameters so that it would not be neces- 
sary to perform the whole iterative (and computationally ex- 
pensive) process of solving the S : problem for every given 
new scheduling scenario. The S** : objective is to specify a 
means of easily estimating the best (i.e., optimal) choice of 
the schedule-generation algorithm’s internal parameters, us- 
ing (abstracted) information about the given scheduling sce- 
nario itself. 

No reason has been identified to suspect that the so- 
lution space is so ill-behaved as to render it impossible to 
find a reasonably accurate means of estimating an optimal 
choice of the values of the algorithm’s internal parameters 
for “points” in the solution space that are “between” other 
points for which the optimal choice has actually been calcu- 
lated (as a solution of the S' problem). However, the remain- 
der of this section (which describes an approach for solving 
the S :: problem) may be regarded as somewhat speculative 
in the sense that (a) the author has performed only a limited 
amount of relevant experimentation (as mentioned earlier in 
Section 2.4.6 (page 15)) and (b) the author’s proposed use 
of certain function-fitting (regression-analysis) techniques, 
while plausible, is not accompanied by a thorough support- 
ing analysis. It is assumed that available computing plat- 
forms are adequate for solving the problem, and that some 
regression-analysis technology must suffice. 

To enable a regression-analysis approach, we make use of 
a scheduling-scenario characterization function: 

Definition 122 (Scheduling Scenario Characterization): 

A : T ->• N 8 9 7 = {L^O^I^P^M^R*) G T => 

3(xi, ...,i 8 )eN 8 3 A(t) = ( 27 , ■ • • , x 8 ) and 


1 . Q = jr = (r 1; . 

. . , r 17 ) G : r 4 = “NIL” 

27 = Q 


2 . Q = jr = (77, . 

. . , nr) G R * : U ± “NIL” 

X 2 = \Q\ 



3. 

Q 


II 

m 

Or, 


■ 1 7*17) G RKp is an element of 


the 

: sequence 7*3 


Xc 

; = |<?| 

4. 

Q 


II 

m 

(n,. 


,n 7 ) g RK 



M = 

= (Mi,--- 

,M 5 ) 

e 

M^,p 2 =r A y “NIL”j => 



X4 

= \Q\ 




5. 

x 5 

= 

A# 




6. 

x 6 

= 

O# 




7. 

x 7 

= 

I# 




8. 

x s 

= 

P# 





The function A produces an eight-dimensional “point” in 
N 8 , and, in relation to the S :: problem, we assume that, for 
two scheduling scenarios 7, 7', the ordinary Euclidean dis- 
tance 

2=1 

between two points 

a = A(7) = (ai, . . . , o 8 ) G N 8 

a' = A(Y) = a' 8 ) € N 8 

representing the characterizations of 7 and y', respectively, 
corresponds to (is commensurate with) the “distance” be- 
tween 7 and y'. 

7.2. Regression- Analysis Approach 

In the following paragraphs relative to solving the S :: 
problem, we assume the availability of an effective 
regression-analysis technique such as artificial neural net- 
works, Bayesian networks, or support vector machines. 

Regression analysis [18, 27]), a collection of well-studied 
methods of modeling multi-dimensional data interrelation- 
ships, is assumed to be viable as a means to derive a func- 
tion for rapidly estimating, for an arbitrary scheduling sce- 
nario, the optimal choice of the values of the internal param- 
eters of the schedule-generation algorithm. 

Regression analysis (or simply “regression”), in the broad 
sense, is analogous to simple least-squares curve fitting with 
one independent scalar variable and one dependent scalar 
variable. Regression aims to fit a hypersurface to the set of 
known data points in the solution space. The best-fitting hy- 
persurface can be expressed as a function that returns the de- 
pendent value given the independent value. In the S :: prob- 
lem, the independent value would be the scheduling scenario 
(or, normally, the tuple that characterizes a scheduling sce- 
nario (i.e., the value returned by the function A (see Defini- 
tion 122 (page 40))), and the dependent value would be the 
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estimate of the optimal choice of the values of the internal pa- 
rameters of the schedule -generation algorithm. 

The essential, broad steps in applying a regression- 
analysis approach to the S S: problem are as follows: 

Algorithm 3 (Algorithm for Optimal-Internal-Parame- 
ters Estimation): 

Given: 

• A set F C F of realistic/actual scheduling scenarios. 
The results of running an implementation of the present 
algorithm are highly dependent on the number and dis- 
tribution of these scenarios. If the accuracy of the es- 
timation function generated by this implementation is 
not deemed adequate, then T' would need to be re- 
vised and used in a fresh rerun. (Over the past three 
decades, a great many actual scheduling-problem sce- 
narios have been constructed and solved by the NASA 
space-data communications scheduling system. These 
scenarios would be a rich (and probably the most ap- 
propriate and reliable) source of data for building the 
set F.) 

Perform the following steps: 

1. For each 7 £ T', 

(a) solve the S : problem computationally, producing 
the optimal choice e of the values of the internal 
parameters of the schedule-generation algorithm, 

(b) compute the characterization c = A( 7 ). 

2. Retain the set Q of known (calculated) points (c, e), as 
obtained in step 1 . 

3. Randomly assign each member of the set Q to either of 
two (approximately equally numerous) disjoint sets: a 
training set Q train and a test set Q t est 9 

|Qtrain| |Qtest| £ { 1 ? 0 ; 1 } 

4. Perform regression analysis using the training data set 
Qtrain, resulting in the determination of the internal- 
parameters-estimation function that best fits the mem- 
bers Of Q train- 

5. Using the test data set Qtest, test and verify the estima- 
tion function derived in step 4. 

6 . If the derived function passes the test, let / designate 
the derived function (which represents the fitted hyper- 
surface) and exit indicating success. If the derived func- 
tion fails the test, then exit indicating failure, calling 
upon the user to alter the given set of actual/realistic 
problem scenarios (e.g., by increasing their number 
or variety) (noting that this alteration gives an altered 
problem) and rerun the algorithm. 


The derived function / estimates the optimal choice of 
the internal parameters of the schedule-generation algorithm, 
given any scheduling scenario. This function can be incor- 
porated into a fielded scheduling system to maximize overall 
performance, and can be used as specified in Section 7.3. 

7.3. Operational Use of Derived Estimation 
Function 

The resulting tested and verified estimation function (speci- 
fied as in Algorithm 3) would then become a tool for oper- 
ational use within a fielded data-communications scheduling 
system. The routine use of this tool would involve the follow- 
ing straightforward steps: 

Process 1 (Operational Use of Estimation-Function): 

1 . Prepare a scheduling scenario 7 . 

2. Supply the characterization A( 7 ) as input to the estima- 
tion function. 

3. Capture the estimation-function output e — the estimate 
of the optimal choice of the schedule-generation algo- 
rithm’s internal parameters for scheduling scenario 7 . 

4. Use e in configuring the schedule-generation algorithm 
for an execution run to produce an optimal schedule for 
7- 

7.4. The Problem: Discussion 

The regression analysis technology called for in Algorithm 3 
is associated with extensive research and application litera- 
ture [2, 4, 6 , 9, 14, 16, 21, 23, 24, 27, 30]. For the overall al- 
gorithm optimization approach specified in Section 7 for the 
S^ problem, it may be unjustifiable to assume the ready ap- 
plicability of off-the-shelf applications. Effective use of the 
relevant techniques and available applications may require 
trial-and-error efforts and/or the guidance of experts. 

It is explicitly assumed herein that: 

• optimizing the internal parameters of the schedule- 
generation algorithm (see Section 6 ) is feasible 

• the relationship between the independent variables (the 
problem-scenario characterization) and the dependent 
variables (the solution found with fixed computing re- 
sources) is smooth enough to support approximation by 
means of some available regression analysis technique 
analogous to a standard curve-fitting technique . 

• the optimization would be effective in the follow- 
ing sense: a system that implemented the schedule- 
generation algorithm would require less computing 
resources and have more rapid response in produc- 
ing high quality schedules, if it took advantage of the 
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optimization of the choice of the values of the inter- 
nal parameters, than if otherwise. 

This set of assumptions has been tested by the author only 
preliminarily (relative to the prototype implementation of the 
unpublished predecessor of the algorithms in the present dis- 
closure) and may, with experience, prove to be unjustified 
with respect to the problem. For example, it may be 
found that, while the first two assumptions are confirmed to 
be valid, the third one is not: the relationship identified in 
the second assumption may be found to be essentially flat. It 
would seem more likely, however, that the relationship identi- 
fied in the second assumption lacks sufficient smoothness to 
support any reasonable optimization process using the sug- 
gested hypersurface-fitting technologies. A determination on 
this question would require involvement of experts in any 
such technology chosen for use. 

The effort needed to obtain a usable function for esti- 
mating the optimal values of the internal parameters (as de- 
scribed in the present section) would be nontrivial, but it 
would be a one-time effort with a potentially worthwhile in- 
crease in operational efficiency of the scheduling system as a 
whole. In carrying out the effort, it might be learned that no 
significant variation in solution quality resulted from differ- 
ent choices for the internal parameters. In that event, the de- 
termination could be made that the effort had insufficient re- 
turn and could be discontinued. 

8. Implementation 

8.1. Prototype Implementation of Predecessor 
Algorithm 

The author implemented the unpublished predecessor of the 
foregoing algorithms (see Sections 5 and 6) for a proto- 
type automated interference-mitigation scheduler and tested 
it with input data for selected scheduling scenarios for three 
actual NASA missions. For these limited cases, the proto- 
type (some 54,000 lines of C++ code) performed with effi- 
ciency at a level adequate for practical use — even when exe- 
cuted on the 1995-vintage Unix workstation available at the 
time. A limited comparison of results with output from the 
Network Planning and Analysis System (NPAS) [31] devel- 
oped at NASA Goddard satisfied the author as to the validity 
and practicality of the approach. 

In implementing the prototype, the author noted the util- 
ity of a mathematically precise specification of the algo- 
rithms. Such a specification clearly supports implementabil- 
ity. It seems reasonable to believe that an implementation at- 
tempted without such a specification but with only a typi- 
cal set of system requirements (a) would entail considerable 
risks of software rework as high level requirements became 


better understood and fleshed out in detail and (b) would re- 
quire a multiple of the schedule time and funding that would 
be sufficient with a specification as precise and complete as 
the one provided in this disclosure. 

8.2. Implementing the Disclosed Methods and 
Algorithms 

The present version of the algorithm improves upon — but 
maintains the essence of the approach of — its predecessor. In 
particular, readability, implementability, and solution-space 
coverage are all improved. The present version should also 
be more adaptable to accommodate inevitable changes in the 
communications infrastructure, e.g., changes required to im- 
plement possible new capabilities for supporting future ex- 
ploration of the Moon and Mars. 

The implementation of the predecessor algorithm sug- 
gests no significant question as to the implementability of 
the method and algorithm disclosed herein (see Section 5 
(page 35)), given that the software-system design process is 
carried out by individuals with an adequate background in 
NASA’s Space and Ground Networks, mathematics, and ap- 
propriate regression analysis techniques (if the implemen- 
tation of the S : ** algorithm (Algorithm 6.3 (page 38)) were 
planned). 

Any programming language that is in use in present 
software implementation projects in NASA’s data- 
communications network infrastructure, such as Java 
and C++, possesses characteristics that would assure suc- 
cess in implementing the disclosed algorithms. However, 
preference should be given to a language that is also sup- 
ported on an available supercomputer or grid computing sys- 
tem for the purpose of running the scheduling system’s 
internal-parameter optimization method described in Sec- 
tion 6 and especially the further algorithm for deriving an 
estimator function for the optimal values of the internal pa- 
rameters as described in Section 7. These algorithms (as 
distinguished from the schedule-generation algorithm it- 
self) are very compute-intensive and should be carried out on 
the most powerful available computing system, not on the or- 
dinary computers that would be used for development or 
operations. 

An operational implementation of the herein disclosed 
schedule-generation algorithm (Algorithm 1 (page 35)) 
might, in terms of size, be comparable to the prototype im- 
plementation of the predecessor algorithm. However, under 
current NASA system-development guidelines, opera- 
tional systems must be implemented with more-stringent 
development standards than were used for the earlier pro- 
totype implementation, and, further, must accommodate 
interfaces with existing operational systems. Conse- 
quently, the necessary size of an operational implementation 
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of a new scheduling system based on the present disclo- 
sure is presently undetermined but is likely to greatly exceed 
that of the prototype. 

Many organizations (including NASA) require systems 
developers to follow a rigid software and systems develop- 
ment methodology, and have adopted one of the recognized 
“process models” that prescribe methods and practices for 
software and systems engineering. For example. Capability 
Maturity Model Integration (CMMI) and ISO 9000 have both 
been followed by NASA. Nothing in this disclosure is in- 
tended to favor or limit or to be incompatible with any choice 
of process model. Nevertheless, the approach taken in this 
disclosure is in the category of a “formal method”, where 
rigorous mathematical language is used in all definitions and 
in all specifications of algorithms for solving problems in a 
given problem domain. The author views such a formal (that 
is, mathematical) approach to be not only inherently advan- 
tageous, but also complementary to whatever process model 
is followed. (See Revisions and Changes Digest item 23 on 
page 67.) 

9. Conclusion 

The present disclosure describes an evolutionary (i.e., proba- 
bilistic) search strategy as the primary approach for attaining 
an optimal solution of the scheduling problem in the civil- 
ian or military space data-communications network. In terms 
of computer processing time for a problem domain of this 
kind (whose solution space is so large that no direct algo- 
rithmic prescription or brute-force method will suffice (see 
solution-space analysis in Subsection 2.2)), a probabilistic 
search application of the kind specified herein progresses, af- 
ter an initial rapid improvement in quality, monotonically in 
an iterative fashion towards (but without any expectation of 
actually arriving at) some evident (but nevertheless unspeci- 
fiable) limiting result (relative to some prescribed measure 
of “goodness” of solutions) that could not be improved upon 
through any amount of processing. 

At any point during processing, the amount of additional 
processing time that would be necessary to achieve an ad- 
ditional improvement over already-found solutions becomes 
greater and greater as the search proceeds. Even if no pre- 
scriptive method exists by which to find an optimum in any 
absolute sense, a probabilistic search strategy can approach 
arbitrarily close to the limiting result, given unlimited pro- 
cessing resources and time. But, as was observed in Sub- 
section 2.4.5, it is not known how to determine how close 
to the optimum is the best solution attained at any inter- 
mediate point in the processing. The existence of a limit- 
ing result (an optimum) seems intuitive, but in practice and 
in theory, the limiting result cannot assuredly be attained. 


Nor can the limiting result actually be specified directly by 
any method — otherwise, logically, an optimum solution it- 
self would be at hand by the same method. 

Nevertheless, it is well known that probabilistic search 
techniques and methods of the kind described herein can 
be used to reach optimal solutions for scheduling prob- 
lems, which leaves an opening for the herein disclosed at- 
tack on the space data-communications scheduling problem. 
The rigorous specification of a system based on these prob- 
abilistic search techniques and methods is presented fully 
herein for the NASA space data-communications schedul- 
ing problem, with no known previous equivalent. While 
evolutionary search techniques have been proposed (e.g., 
see [25, 28, 32, 12]), no other true optimizing scheduler for 
this problem domain is known to have been fully specified. 

A number of constraints must be considered in design- 
ing any system that solves the space data-communications 
scheduling problem. The methods and algorithms disclosed 
herein incorporate, among others, the RF-interference miti- 
gation constraint, with the objective of assuring that the sys- 
tem generates high quality schedules that accomplish over- 
all goals of the space data-communications infrastructure. 
How and to what degree interference predictions should fi- 
nally constrain schedules represents an issue in the design of 
such a system. While the algorithm as disclosed herein does 
satisfy RF-interference mitigation constraints, it does not ex- 
plicitly provide for fine-grained control of this factor; how- 
ever, a modification to do so could be incorporated without 
difficulty. Fine-grain control of this constraint could, for ex- 
ample, include a further parameter in the definition of mis- 
sion event (see Definition 46 (page 22)) to indicate whether 
or not to apply the constraint for a prescribed instance of a 
prototype event relative to that mission-event instance. 

While the primary context of the present disclosure relates 
to NASA, the method and algorithm have broader applicabil- 
ity, and, despite domain differences, should readily be adapt- 
able for the military context. 

Two abstractions related to the overall problem of devis- 
ing the most cost-effective possible system for generating op- 
timal schedules were developed in Section 6 (page 37) (the S' 
problem) and Section 7 (page 40) (the S : ® problem). In pre- 
senting the former abstraction. Section 6 described a method 
and algorithm that increase the efficiency of the search for the 
optimal schedule given a scheduling scenario 7 , by applying 
an iterative process for determining the optimal choice of the 
values of the schedule-generation algorithm’s internal param- 
eters. For the given scheduling scenario 7 , any other choice of 
the values of the schedule-generation algorithm’s internal pa- 
rameters would mean either decreasing the expected quality 
of the generated schedule or increasing the expected search 
time for a schedule of a given quality (relative to some pre- 
scribed measure of “goodness”). In presenting the latter ab- 
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straction (in a somewhat speculative vein unsupported by ex- 
perimental results). Section 7 builds upon the method and al- 
gorithm in Section 6 and describes a further method and ap- 
proach by which to obtain an estimator function that, given 
a scheduling scenario (or its characterization via a charac- 
terization function), would return an estimate of the optimal 
choice of the values of the schedule-generation algorithm’s 
internal parameters, thus assuring (in the full embodiment 
and application of the technology disclosed herein) the most 
cost-effective possible system for operational use in gener- 
ating optimal, constraint-satisfying schedules for the civilian 
or military space data-communications infrastructure. 

Appendix A explores an assumed model of the perfor- 
mance of the probabilistic search techniques described in the 
main body of the present disclosure. Analysis of the model 
imparts understanding and insight into the issue of how the 
disclosed evolutionary-search algorithm’s internal parame- 
ters might be set to maximize performance of the system in 
operational use. 

Finally, Appendix B describes a class of problem domains 
(the Type-G problem domains), which encompasses a very 
broad range of optimization problems including the space 
data-communications scheduling problem, among many oth- 
ers. A rigorous specification of algorithms and methods for 
reaching optimal solutions for problems of Type G is dis- 
closed. The disclosed specification affords to developers an 
efficient implementation path for developing systems to solve 
such problems. 


10. Appendix A. Algorithm 
Performance 


10.1. Best-Solution Fitness (Function of 
Algorithm-Iteration Count) 


To gain insights into the nature of the optimization at- 
tainable by the schedule-generation algorithm (Algo- 
rithm 1 (page 35)) and the S' algorithm (Algorithm 2 
(page 38)), we will assume and analyze a model for the per- 
formance of the schedule-generation algorithm. We will as- 
sume that for a given scheduling scenario 7 and a given 
choice e of the values of the internal parameters of the 
schedule-generation algorithm, the solution (schedule) fit- 
ness plotted against the iteration count during a run of 
the algorithm would be representable by a function hav- 
ing the form: 


f(p) 


v 

(p — u) z + w 


+ q 


(i) 


where the independent variable p £ N + represents the it- 
eration count during a run of the algorithm, and the depen- 


dent variable /(p) represents the fitness of the best sched- 
ule in the schedule population at the end of that iteration. 
The values of the parameters v,u,w,q, z £ R. determine 
the precise curve that approximates the performance of the 
schedule-generation algorithm (for the given scheduling sce- 
nario 7 and given choice e of the values of the internal param- 
eters). The rationale for choosing a function with the form of 
Equation 1 is partly empirical, but is herein unexplored ex- 
cept for Subsection 10.2 

Figure 4 (page 45) illustrates an instance of the function 
/ (with particular values for the parameters v, u, w, q, and ^) 
along with the derivative of / with respect to p: 

d /(p) = -vz C V~u) z -1 

dp {(p-u) z + w) 2 

Note that the value of /( 0) is finite (assuming (0 — u) z + 
w ^ 0 ), corresponding to the fact that the population of ran- 
domly formed solutions at the initialization of the run of the 
schedule-generation algorithm (Step lc, page 35) will have a 
range of fitness scores, all of which will be finite values. The 
intersection of the function / with the vertical axis represents 
the best score in the range of scores of the members of the ini- 
tial population. Of course, a negative iteration count is mean- 
ingless and so the model f for the performance of the algo- 
rithm as a function of algorithm-iteration count has no mean- 
ing to the left of the vertical axis. 

An everywhere differentiable monotonic function (such as 
/) has a monotonic derivative, and in the case of the present 
model, the derivative is always negative, corresponding to 
the fact that the assumed fitness model is a function whose 
slope is always negative — corresponding, in other words, to 
the fact that the fitness, in general, improves with increas- 
ing iterations of the schedule-generation algorithm. Note that 
the rate of improvement decreases with increasing iterations 
of the schedule-generation algorithm. 

10.2. Assumed-Model Versus Actual 
Performance 

Whether such a function (Equation 1) could be a fair rep- 
resentation of the actual performance of the schedule- 
generation algorithm makes a reasonable question that is dif- 
ficult to answer in the affirmative, but it can be argued that at 
least some such function would be a worst-case representa- 
tion. 

The actual performance of the schedule-generation algo- 
rithm, as previously indicated, is, for a given run of the al- 
gorithm, a discrete (and monotonic) function of the iteration 
count during the run. That is, the quality of the best schedule 
in the population at the end of an iteration will be the ordinate 
of a discrete point whose abscissa is the iteration count, and. 
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Figure 4. Best-Solution Fitness modeled as a 
function of the schedule-generation algorithm 
iteration count (upper curve) (Equation 1), with 
its derivative (lower curve) (Equation 2). Points 
on the graph to the left of the vertical axis are 
to be ignored, since they are meaningless in 
relation to the actual performance of the al- 
gorithm. The model for fitness is assumed to 
be a continuous function, whereas the actual 
performance is a set of discrete points, one 
for each integer representing the schedule- 
generation algorithm iteration count. 


plotted against iteration count, all such points resulting from 
the run will be separate dots on the graph, as illustrated in 
Figure 5. Since the performance of the schedule-generation 
algorithm has a monotonic relation to the iteration count, if g 
is the set of points representing the performance of any given 
run of the algorithm, then there exists a model — i.e., an in- 
stance /worst of Equation 1 (with some choice of the values 
of the parameters v, u , w, q, and z ) — such that 



Figure 5. Best-Solution Fitness versus it- 
eration count. The discrete points in the 
lower graph represent a hypothetical run of 
the schedule-generation algorithm. The up- 
per curve is a graph of Equation 1, the as- 
sumed model of fitness as a function of it- 
eration count during a run of the algorithm, 
with choices for the values of the parameters 
v,u,w,q, and z so as to obtain a best-fitting 
curve of the form of Equation 1 having the dis- 
crete points as a lower bound. 


1. 3a; G dom(g) 3 g( x) = /„ or st(», and 

2. Vx G dom (g) 3 g( x) < / w orst(» 
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and we can refer to this instance of Equation 1 (see Figure 5) 
as the worst-case model of the actual performance. In the re- 
maining subsections of this appendix, the worst-case model 
can be considered to be the subject of the discussion. 

Two further observations are offered regarding Figure 5. 
First, the discrete points in the lower graph are merely repre- 
sentative and are not actual data from a run of the algorithm. 
However, the lower graph is notionally consistent with ac- 
tual execution results of genetic-algorithm applications gen- 
erally (for example, see [28]). Second, the Equation 1 model, 
even if it is the worst-case model as depicted in the upper 
graph in Figure 5, suggests a means of judging a trade-off 
between the quality of the results from running the algorithm 
and the power of the computing resources (or the processing 
time) needed. The model represented by the upper graph has 
a kind of “knee” where the slope of the curve changes more 
rapidly than for points either to the left or to the right. To 
the right of the knee, there is a diminishing-returns situation. 
The farther to the right, the less improvement in schedule 
quality expected from a run, but the more computing power 
(or processing time) required to attain that improvement. To 
the left of the knee, there is a larger gain in improvement 
for a given increment in additional computing power (or pro- 
cessing time). In view of the diminishing returns of applying 
more processing resources at the far right end of the graph, 
one insight gleaned from considering the model (even the 
worst-case model) is that reaching a judgement concerning 
a trade-off between computing power (or processing time) 
and the quality of the results from running the algorithm can 
be expected to be facilitated by actual experience running the 
algorithm. Further, such experience would augment under- 
standing as to how quickly the “knee” will be reached, as 
well as how long it may take to reach the point of negligi- 
ble expectation of further improvement 6 . 

10.3. Fitness as a Function of a Single 
Parameter 

We now consider the behavior of the model when a full run 
of the algorithm is repeated with a change in the value of 
one of its internal parameters. In the repeated run, no other 
change is imposed. For the present discussion, we let the pa- 
rameter n represent the change in the value of internal pa- 
rameter otj (see definition of a in step le of the specification 


6 These expectations are perhaps reminiscent of the law of diminishing re- 

turns — an interesting relationship between production and effort in the 
sense studied in economic theory. It may also remind the reader of an- 
other diminishing-retums situation found in Einstein’s Special Theory 
of Relativity in which any constant application of energy applied to in- 
crease the speed of, for example, a spacecraft eventually produces a van- 
ishingly small increase in speed as relativistic effects cause the space- 
craft mass to increase without bound. 


of Algorithm 1 (page 35)). Thus, in each iteration of the al- 
gorithm during the repeated run, at step j + 4 (noting that 
step 4 (page 36) is the first step performed in each iteration) 
the number of candidate schedules to be generated for inclu- 
sion in the population will be changed by the value of n. 



Figure 6. Best-Solution Fitness as a function 
of the parameter n (representing the change 
in the fixed number of new members gener- 
ated at each step) for the assumed model (see 
Equation 6). 


For the initial run (which is assumed to have reached a 
point in the processing where a large additional amount of 
processing would not entail a significant expectation of im- 
provement in the fitness of the best schedule, thus reaching 
an optimum), let p denote the total number of iterations, so 
far, of the steps of the schedule-generation algorithm, and let 
m s denote the number of schedules (i.e., solutions) gener- 
ated and considered during the run. Then 

m s = n 0 + pn 0 (3) 

where no is as defined in step lb (page 35). 

When the run is repeated, the total run time will be the 
same (governed by the run-time limit v defined in step la 
(page 35)). The generation and evaluation of the schedules 
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created during a given iteration will consume a greater or 
lesser total amount of computation time, and will decrease 
or increase the number of iterations of the algorithm during 
the run, but the total number of schedules that can be gener- 
ated and evaluated during the repeated run will be the same, 
equal to m s , as for the initial run. Thus, with m s constant be- 
tween the runs, for the repeated run, we have 

m s =n 0 + p(n 0 + n) (4) 


and so the iteration count can be considered to be a function 
of n £ N, the independent variable representing the change 
in the number of new schedules that will be added in some 
prescribed step of the schedule-generation algorithm: 


P(n) 


m s - n 0 


n 0 + n 


(5) 



Figure 7. Derivative of best-solution fitness as 
a function of n (representing the change in the 
fixed number of new members generated at 
each step) for the assumed model (see Equa- 
tion 7). 


Equation 1 can now be rewritten to express the fitness 
function in terms of n: 


/w 


V 


( m s —n o 
n 0 +n 



+ q 


(6) 


illustrated in Figure 6. Notice that the fitness worsens for ev- 
ery positive value of n: the slope of the graph is everywhere 
positive. The derivative of f(n), given by Equation 7 and il- 
lustrated in Figure 7, is always positive, approaching the hor- 
izontal axis asymptotically. 


d f(n) 
d n 


vz (m s - n 0 ) 


« m s —n 0 
n 0 +n 



( m s —rip 
n 0 +n 



(n 0 + n ) 2 


(7) 


From these observations it is seen that a larger value of n 
worsens the fitness by a greater amount than does a smaller 
one, but the effect diminishes with ever larger values of n. 

Thus, when the algorithm’s performance is directly related 
to the number of iterations of the steps of the algorithm, as 
in the assumed model (Equation 1), the following questions 
arise: 

First, does the model of fitness as a function of n (the 
change in the number of candidate schedules generated in 
some prescribed step in each algorithm iteration for inclu- 
sion in the population in the repeated run) (see Equation 6 
(page 47)) imply that arbitrarily increasing the value of an 
internal parameter necessarily brings a decrease in the qual- 
ity of the best solution (schedule) — in comparison to the best 
schedule that can be produced in the number of iterations per- 
formed in the initial run? 

Second, does the model imply that decreasing the value of 
an internal parameter in the repeated run necessarily brings 
an increase in the quality of the best solution (schedule) — in 
comparison to the best schedule that can be produced in the 
number of iterations performed in the initial run? 

In each run of the algorithm (when used as specified 
in Algorithm 1), values of the internal parameters are held 
constant (i.e., the number of candidate solutions (schedules) 
added in each of the algorithm’s steps 4 through 15 (page 36) 
remains the same until the end of the run). At the end of the 
run (the duration of which will equal the run-time limit v ), 
the system will output the best schedule in the population. 
In a repeated run with the increase/decrease of n in the num- 
ber of candidate schedules generated in each iteration, even if 
all other parameters are held the same, at any given iteration 
number, say the fcth, the algorithm will necessarily have con- 
sidered either more schedules or fewer schedules (depending 
on whether n is positive or negative), and from the first iter- 
ation onward, the population of schedules will increasingly 
diverge from the population in the initial run. Therefore, the 
model assumed in Equation 1 has limited use in answering 
the stated questions, but nevertheless affords a useful insight 
into the setting of the algorithm’s internal parameters, as dis- 
cussed in the next section. 
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10.4. Fitness as a Function of Elapsed Run 
Time 

It will now be insightful to analyze the behavior of the fit- 
ness model (Equation 1) as a function of the elapsed run time 
of the algorithm, when holding fixed the value of n (i.e., the 
variable representing the change in the value of a single inter- 
nal parameter as described in the preceding section). In this 
analysis, we assume we are given the following: 

1 . v, the duration of the algorithm execution run 

2. no, the number of schedules added to the population 
during each iteration of the steps of the algorithm 

3. n, the change (relative to a previous run) in the value of 
a single internal parameter as described in the preced- 
ing section 

4. to s , the total number of schedules that can be added 
and evaluated during a run of duration v seconds as de- 
scribed in the preceding section 

With the above given information, we seek to reformulate 
Equation 1 to calculate the fitness of the best member of the 
evolving population of schedules as a function of time. 

Since m s schedules can be created and evaluated by the 
algorithm during a run of v seconds duration with the as- 
sumed given computing resources, the time required to cre- 
ate and evaluate each schedule (as an overall average) is 

v 

m s 

When the iteration count is p during a second run of the 
algorithm, the cumulative number of schedules added will be 

n cum = n 0 + (n 0 + n)p 


It is now possible to calculate how much time has elapsed 
when the run reaches iteration p : 


v 

m, 


t = n cum — = (n 0 + (n 0 + n) 
m s V 

We can now express the iteration count p as a function of 

m s t - n 0 v 

P(t) = 

Thus, Equation 1 can be rewritten to relate fitness to 
elapsed run time t: 


t: 


/(*) = 


m s t—n qv 

(no+n)» 


( 8 ) 


— M + W 


two curves is that, given any two runs of the algorithm where 
the first has a larger, and the second has a smaller, number n 
of schedules added in each iteration, and given any particu- 
lar elapsed time t during each run, the run that has the smaller 
value of n will have a better value of the fitness of the best 
member of the population at time t. The two curves illus- 
trate the fact that the effect is greatest at the beginning of the 
run and necessarily vanishes at the end when the elapsed time 
equals v. 



Figure 8. Fitness modeled as a function of the 
elapsed run time, holding fixed the value n for 
the change in the value of a single internal pa- 
rameter. Two runs are illustrated. The upper 
curve has n set to a positive number, while the 
lower curve has n set to a negative number of 
the same magnitude. 


illustrated in Figure 8. In the upper curve, the value of n is 
a positive number, and, in the lower curve, n is a negative 
number of the same magnitude. The conclusion from these 
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However, these relationships are subject to a caveat. In the 
second run of the algorithm contemplated above, the popu- 
lation starting at the second iteration of the steps of the al- 
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gorithm begins to diverge from that of the first run, since the 
number of schedules added in each iteration in the second run 
will be either greater than or less than the number added in 
each iteration in the first run. The model described by Equa- 
tion 1, while arguably representative of the performance of 
the system during any given am, has no relevance to the dif- 
ferences between two different runs. If Equation 8 or Fig- 
ure 8 is at all suggestive of some guidance in setting the val- 
ues of the internal parameters, it would be that smaller rather 
than “large” values would improve performance. 


10.5. Key Insight Afforded by the Assumed 
Model 

Clearly, the model assumed in Equation 1 does imply that in- 
creasing or decreasing the number of iterations in a run in a 
manner that does not result in a difference in the number of 
candidates generated in any step of the algorithm (by, for ex- 
ample, increasing or decreasing the value of u) will, in gen- 
eral, correspondingly affect the quality of the solution pro- 
duced by the algorithm. 

Significantly, the model of fitness as a function of the pa- 
rameter n (see Equation 6 (page 47) and Figure 6 (page 46)) 
implies that the number of new schedules that will be added 
in each step of the algorithm is very important: negative val- 
ues of n result in generating fewer candidate schedules in 
each iteration, and therefore result in a greater number of it- 
erations during the run. This, together with the analysis in 
Section 10.4, leads to the hypothesis that experimentation 
(or, better, the application of the S : algorithm (Algorithm 2 
(page 38))) would show that the optimal choice of the val- 
ues of the internal parameters for a given scheduling sce- 
nario would entail smaller values rather than larger. 

This is perhaps the most useful insight to be drawn 
from considering the above model of the performance 
of the schedule-generation algorithm — namely, that de- 
spite the fact that the specification of the algorithm is 
silent on how to choose the values of the internal param- 
eters, large values would be contraindicated. This insight 
still does not give quantitative guidance on what con- 
stitutes “large” values, however, and therefore does not 
really substitute for the quantitative guidance that ulti- 
mately would be available when a solution to the S :i prob- 
lem is implemented as described in Section 7 (page 40). 
But the stated insight suggests that even routine experi- 
ence running an implementation of the schedule-generation 
algorithm would eventually lead to a level of practical under- 
standing of at least how not to set the values of the internal 
parameters. 


11. Appendix B. The Generalized 
Algorithms and Methods 

11.1. The General Problem 

11.1.1. Introduction 

In this appendix, we present a generalization of the methods 
and algorithms (and of the problem domain itself) that were 
described in Section 5 (page 35), Section 6 (page 37), and 
Section 7 (page 40). Reaching toward such a generalization 
is motivated by the recognition (a) that there are many dif- 
ferent problem domains where an evolutionary search strat- 
egy can be used profitably, and (b) that application developers 
may benefit from having such a generalization when translat- 
ing to another domain the methods and algorithms that were 
described herein for the NASA space-data-communications 
scheduling problem. 

The generalization presented in this appendix is intended 
to facilitate development of applications for any problem do- 
main matching the essential characteristics of the Type-G 
problem domain defined below. While the Type-G problem 
domain is not all-encompassing, it is general enough to be 
broadly useful and has certain characteristics that facilitate 
implementation as well as efficient computation. (For ex- 
ample, integer values suffice for the vast majority of all of 
the calculations that are required for execution of the algo- 
rithms.) 

This appendix also delineates steps for implementing the 
generalized methods and algorithms. 

Material to be presented below starts with a description 
of Type-G problems and the approaches for reaching opti- 
mal solutions to such problems, and progresses then to de- 
scriptions of Type-G problem abstractions that, along with 
methods to solve them, are designed to support the optimiza- 
tion of those approaches themselves, for use in fielded sys- 
tems that solve Type-G problems. The abstractions, based on 
the idea of Type-G meta problems, are referred to as the G : 
and G^ problems. 

11.1.2. Basic Definitions 

In the case of the earlier treatment of the NASA space- 
data communications-scheduling problem, a problem sce- 
nario was a set of data structures that, in part, expressed user 
requirements for data-communications events by which sci- 
ence data (among other kinds of data) could be returned to 
earth via antennas in the NASA data-communications sup- 
port infrastructure, or by which commands or other types 
of data could be received from earth by the user spacecraft, 
again via antennas in the NASA data-communications sup- 
port infrastructure. A problem scenario also contained addi- 
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tional data structures comprising infrastructure constraints, 
characteristics of support antennas, etc. 

Similarly, in the case of the generalized problem domains 
that we are discussing in the present section, a problem sce- 
nario is a finite data structure that expresses requirements and 
constraints that a problem solution must satisfy. 

Definition 123: 7 is a problem scenario of Type G => 3k £ 
N+ 3 7 is a sequence of exactly k finite data structures that 
expresses requirements/constraints that are internally consis- 
tent and that every allowable solution for 7 must satisfy. 

Definition 124: 

r = {7 : 7 is a problem scenario of Type G}. 

T is the set of all possible problem scenarios of Type G. 

Definition 125: T dim : N 1 — y p(T) 9 

V(fc, 7) G N + x T, 7 G r dim (fc) len(7) = k. 

T d i m (k) is the set of all problem scenarios of length k (i.e., 
of dimension k). 

Relative to the optimization issues addressed in this dis- 
closure, we will refer to problem domains of Type G defined 
as follows. 

Definition 126: A = j<5: 3k £ N + 3 6 C r dim (fc)|. 

Definition 127: 

6 is said to be a problem domain of Type G if and only if 

S £ A. 

A problem domain of Type G is a set of Type-G problem sce- 
narios all having the same dimension. 

Note that the term “Type-G problem”, as distinct from the 
term “Type-G problem domain”, will have a more specific 
definition (see Definition 136 (page 53)). 

Definition 128: A dim : A ->• N + 3 V(< 5 , k) £ A x N + , 
A dim (<5) = k [V7 e <Men( 7 ) = k] 

A d j m ((5) is the dimension of S, i.e., A d j m (<5) is a positive in- 
teger representing the length of every problem scenario in < 5 . 

We now identify the set of all permissible solutions for 
Type-G problem domains. 

Definition 129 (Set of All Permissible Solutions): 

© = {0:3<5eA,37e<53 

9 is a permissible solution for problem scenario 7 j. 

0 is the set of all permissible solutions for all problem sce- 
narios 7 £ S £ A, with no omissions or exceptions. The 
problem-domain dependent notion of “permissible” is left 
undefined. 

Definition 130 (Set of All Permissible Solutions for a Given 
Problem Scenario): 


©scenario : A X T X p(©) 3 

V(tf, 7)eAxr9 7 eMe ©scenario {8, 7 ) 

8 is a permissible solution for problem scenario 7. 

Definition 131: Dq = {x: 3n £ N + 3 x £ Z”} 

Dq is the set of all tuples whose elements are integers. (See 
Revisions and Changes Digest item 24 on page 67.) 

11.1.3. Associating Generalized Problem Domains with 
Real Problem Domains 

It will be taken for granted herein that the context for discus- 
sion relates to a certain class of real-world problems for each 
of which the following hold: 

• it can be stated in some proper manner and given an ap- 
propriate working association with some member of A, 

• it has a definable solution that can be expressed as a fi- 
nite data structure, and 

• its implementation following the generalized methods 
and algorithms disclosed herein would flow from the 
actual problem statement and its associated member of 
A. 

The way in which a problem domain in this class might 
be given an association with a member of A, and the specifi- 
cation of the implementation of the actual problem statement 
in the context of the generalized methods and algorithms, are 
each beyond the scope of this disclosure. 

The foregoing definitions lead to the following observa- 
tions concerning a problem domain of Type G: 

1 . There exists a fitness function that assigns to each per- 
missible solution for any given problem scenario a 
quantitative “goodness” or “fitness” score. 

2. Every problem scenario has an optimal solution with 
reference to a given fitness function. 

Type-G problem domains are numerous and varied, and 
include not only the schedule-optimization problem ad- 
dressed earlier by means of evolutionary search (genetic 
algorithms) (Section 5 (page 35)), but also the meta prob- 
lem designated as the S : problem that likewise was addressed 
by means of evolutionary search (genetic algorithms) (Sec- 
tion 6 (page 37)). 

11.1.4. A Note on Applicability 

While in theory the disclosed generalized methods and algo- 
rithms could be used to reach a solution to many problems 
for which standard numerical or closed-form methods exist, 
such usage would be inefficient and would produce less ac- 
curate solutions. Nothing in this disclosure is to be construed 
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so as to obviate common sense in the use of the methods de- 
scribed herein. Only appropriate applications are to be con- 
templated. 

There are numerous appropriate applications of the meth- 
ods and algorithms specified in this appendix for reach- 
ing optimal solutions of problem scenarios of Type G. The 
design-optimization applications in the realm of space mis- 
sions mentioned in Section 1 .6 (page 9) are representative of 
a wide variety of design-optimization problems, from archi- 
tecture to automobiles to industrial plants to rail systems to 
product packaging — to mention only a few that 

• can be found in the literature concerning applications of 
evolutionary search, 

• can be classified as problems of Type G, and 

• therefore can be solved by a system following the meth- 
ods and algorithms specified herein. 

Scheduling and planning generally can be cast as prob- 
lem domains of Type G. But the range of Type-G problems 
is greater yet, and is not likely soon to be fully traversed. 

11.1.5. The Essential Evolutionary Search Functions 

Genetic algorithms, and evolutionary programming, are ap- 
plicable to a broad range of problems (see discussion in Sec- 
tion 2.3 (page 13) and Section 2.4 (page 13)), and form the 
central technical approach for solving Type-G problems as 
presented herein. The essential mechanisms of evolutionary 
search (beyond the basic notion of evolving a population of 
candidate solutions through an iterative process) are — 

• fitness 

• random selection 

• genetic mutation 

• genetic crossover 

These mechanisms will be embodied in functions defined 
below. 

11.1.5.1. Fitness Functions A crucial part of an evolu- 
tionary search algorithm as described herein is the fitness 
function that will be used to evaluate candidate solutions in 
the solution space. A valid fitness function for a given prob- 
lem scenario 7 maps each member of the set of all per- 
missible solutions for 7 to a real number greater than or 
equal to 1 , where unity is the fitness of a perfect solution. 
While other choices for the definition of “perfect” fitness are 
worth considering, the chosen value, 1 , affords certain de- 
sirable numerical advantages for constructing an actual fit- 
ness function. For example, the fitness function defined in 
Definition 102 (page 32) for the space-data communications 


scheduling problem had as constituents a number of inde- 
pendent sub-functions, each defined with fitness in the semi- 
closed real-number interval [l,oo), where the final fitness 
was computed as the product of the values returned by the 
constituent functions, thus ensuring that the final fitness value 
always remained in [l,oo) and, further, that the final fitness 
value strongly reflected the degrading effect of any one of the 
constituent values that exceeded 1 . 

More exactly, 

Definition 132 (Set of All Fitness Functions): 

-/fitness : A X r — > p([l,oo) 0 ) 9 

V(S, 7 ) e A x r , / e F mness (S, 7 ) o 

1. dom(/) = ©scenario (<5,7) 

2. V9, 9' £ ©scenario (6, l), 

f(6) < /($') => 0 is more fit than 9'. 

Ffltness (<^j 7 ) is the set of all possible fitness functions for 
problem scenario 7 in the target problem domain 5. (See Def- 
inition 13 (page 19) for the meaning of the notation of the 
form X Y , where each of X and Y is a set. In the present def- 
inition, [l,oo) e designates the set of all functions that map 
0 to the semi-closed interval [ 1 , 00 ) on the real-number line.) 

11.1.5.2. Random Selection The search strategy also em- 
ploys, for given problem scenario 7 for given target problem 
domain 5, a means to create a set of new candidate mem- 
bers of the working population by either (a) randomly gen- 
erating permissible solutions for 7 or (b) randomly selecting 
members of ©scenario (5, 7 ). 

Definition 133 (Selection of a Random Set of Solutions): 

/randomselection : A X I X P^(p(©)) ^ 9 

^ A X F , f £ /randomselection (/■ 7 ) 

1. codomain(/) C © scenari 0 (( 5 , 7 ), 

2. Vn £ N+,/(n) = RND(n, ©scenario 

Note that a function belonging to /‘random selection is a “pseudo 
function” (see remark below Definition 17 (page 20)). 

The question may arise as to whether it would be advan- 
tageous to “jump-start” the evolutionary search process by 
somehow including at least one known solution in the ini- 
tial working population of solutions. Such a known solution 
might be obtained by employing some special preprocess- 
ing step or some more sophisticated method that could match 
the results achievable, for example, by a human expert. Such 
an alternate approach, then, differs from the approach pre- 
scribed in the above definition of /random select ion. where only 
a true random selection of (permissible) solutions composes 
the initial generation. It might be supposed that the alternate 
approach would increase the expected cost-effectiveness of 
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the search process (i.e., a better average quality of the best so- 
lution produced for a given fixed run time). Even with exten- 
sive experimentation and testing, conclusions on this ques- 
tion would be subject to doubt, for no theoretical framework 
or guidance is in evidence to support the interpretation, anal- 
ysis, validation, and integration of testing data. For example, 
an early question would concern whether the known solu- 
tion produced in the alternate approach had been reached us- 
ing the same goodness metrics in the same manner as given 
in the prescribed approach. If not, then how would the differ- 
ence in the goodness metrics and the manner in which they 
were applied be characterized and accounted for in the fi- 
nal result of any comparison test? Another source of doubt 
would be the very means or agent that produced the solution 
to be used in the alternate approach: in particular, can two 
human experts always be counted upon to produce the exact 
same solution for every given problem scenario, and if not, 
then what is the support for any particular conclusion con- 
cerning the value of the alternate approach? The accurate res- 
olution of doubts regarding the validity and cost effectiveness 
of the alternate approach is difficult to forecast, and the entire 
problem is beyond the scope of the present disclosure. Suf- 
fice it to say that the effort and argumentation required to re- 
solve the doubts would be considerable if not daunting, and 
ultimately of questionable value even if focused on a partic- 
ular problem domain. In summary, as part of an operational 
system, the alternate approach (even if otherwise it is appro- 
priate as a target of research) is difficult to justify on the basis 
of current theory or knowledge in the general field of evolu- 
tionary search, and a more supportable course would be to 
adhere to the approach given in this disclosure. (See item 25, 
page 67, in Revisions and Changes Digest section.) 

11.1.5.3. Mutation Functions Evolutionary search algo- 
rithms also involve functions that generate new candidate 
members of the working population of solutions using mu- 
tation and crossover concepts (see the discussion of genetic 
algorithms in Section 2.4 (page 13)). To generate a mutation 
of a member 9 of the working population during a search, a 
new data structure is created representing the new member 
of the population, i.e., the mutated version of the given mem- 
ber 9. The new data stmcture (a finite data structure by defi- 
nition) will be the same as that of the given member 9, except 
for some deliberate (yet random), problem-scenario-specific 
alterations made by the mutation function. Once created, the 
new member is incorporated into the working population on 
an equal footing with all other members until the member- 
evaluation phase of the search algorithm is reached during 
an iteration through the steps of the algorithm. If by chance 
the mutation produces a child that is identical with its parent, 
then it will be ignored. It may be noted that the mechanism 
for making mutations legitimately may not select purely ran- 


dom parts of the data structure representing a member of the 
population, as such a mutation mechanism would likely pro- 
duce offspring containing uninterpretable/impossible data, 
rendering them impermissible as solutions of the given prob- 
lem scenario. Therefore, it may be taken for granted that the 
mutation mechanism must not lead to nonsensical or other- 
wise impermissible offspring. 

Definition 134: F muta tion : A x T p(e°) a 

V(<S,7) G A x TJ G F mutation {5, 7 ) 

1. dom(/) = ©scenario 7 ) 

2. codomain(/) C © sceiiari 0 ((), 7 ) 

3. 9 G rndmember (0 sce „ a ri O (<5, 7 )) => 

f(9) is a random mutation of 9. 

Fmutation (<5, 7 ) is the set of all possible mutation functions for 
problem scenario 7 in the target problem domain S. Note that 
this function is a “pseudo function” (again see remark below 
Definition 17 (page 20)). 

11.1.5.4. Crossover Functions The crossover mechanism 
is defined similarly. A crossover function accepts two ran- 
domly selected members of the current working population 
and produces, in some random yet problem-scenario-specific 
manner, two new members whose characteristics and fitness 
will be determined partly by each of their “parents” — the two 
given members. Each crossover function operates by identi- 
fying two random crossover points. The crossover points de- 
fine segments of the data structure of each of the parents. 
Once the segments are determined, the two “children” of the 
parents will be assembled from their parents’ corresponding 
segments in such a way that the children differ from each 
other and from each parent — preserving, in that way, the con- 
cept of swapping some, but not all, of the chromosomal ma- 
terial between the parents as a means to produce the chil- 
dren. If by chance the children and their parents do not all 
differ from each other — a result that is not allowed — then it 
will be necessary to repeat the step for randomly selecting 
the parents and the segments to be swapped. It may be noted, 
again, that the crossover points legitimately may not define 
purely random parts of the data structure representing a par- 
ent, as swapping portions defined in that manner would of- 
ten (perhaps nearly always) produce offspring containing un- 
interpretable/impossible data, rendering them impermissible. 
Therefore, it may be taken for granted that the mechanism 
for selecting crossover points must not lead to nonsensical or 
otherwise impermissible offspring. 

Definition 135: F crossover : Axf-> p((© 2 ) 02 ) 9 

V(<5,7) G A x T , / G -^crossover (5, 7 ) <^> 

1 . dom(/) — ©scenario (^5 7 ) > 
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2. codomain(/) C 0 scenario (J,7) 2 , 

3. (0,0') £ rndmember (0 scena rio (<5, y) 2 ), 0 ± O' => 
f(0,0') is a pair (0 c ,0' e ) of children generated as 
crossovers between parents 0 and 0' . 

f crossover (^- 1) is the set of all possible crossover functions 
for problem scenario 7 in the target problem domain <5. Note 
that every member of F crossowr (5, 7) is a “pseudo function”. 

We now seek to formulate the Type-G problem, generally 
applicable to any problem domain of Type G. 

11.2. The Type-G Problem 

A Type-G problem is a member of the set G : 

Definition 136 (Set of All Type-G Problems): 

G C AxTxN+x [O,oo)x£> 0 x (p(0)) N+ x [l,oo) e x 
0 e X (0 2 ) 02 X 0 9 

g = (5,TG5, V, T, a, fr, /test, fm, fc, T 0 £ G => 

1 . v represents, in units of seconds, an adequate run time 
for the search, 

2. t represents a small real value (not necessarily posi- 
tive) that reflects the user’s judgment or policy as to 
how close to perfect a solution for the given problem 
scenario must be to be considered “good enough”, 

3. a is a vector (i.e., a tuple (07, ct 2 , ■ • ■ )) consisting of 
values of the internal parameters of g, with len(oj = 
Adim(<5), 

4- fr £ Gandomselection(^, T), 

5- /test £ Gitnes.s ( 8 , 7)5 

6- fm £ l mutation 

2 ■ fc £ ^crossover( < 5, 7), ^Uld 
8-7 T € G SC enario(/ 7)- 

g is said to be a Type-G problem if and only if g £ G. (See 
Revisions and Changes Digest item 26, page 67.) 

It will be useful to identify the Type-G problems for a 
given Type-G problem scenario 7, as follows: 

Definition 137 (Set of All Type-G Problems for a Given 
Problem Scenario): 

^scenario • AxT7 p(G) 9 V(8,y) € A X r, 

^scenario (*5, 7 ) = { (<*, 7, •) € g}. 

11.3. Type-G Problems: The G-Algorithm 

In moving on toward defining an algorithm for solving a 
Type-G problem, it will be helpful to define a function that 
embodies certain steps that must be performed by the algo- 
rithm relative to a given set of candidate solutions of a given 
Type-G problem: 


Definition 138 (Internal Steps of a G-Algorithm): 

Wsteps : p(0) xG-) p(0) 3 

V(n ,g = (S,y,is,T,a,fr,f test ,f m ,f c ,Tr)) £ p(0) x G 

if 

1. II C ©scenario (^, 7)’ 

2. ^population = ff 1 t j - 

j€{ l,...,len(a)} 

3- |n| > rtpopuiatjon, 

4. ni =RND(ai,n), 

5. n 2 = RND(i a2 , n 2 ) 9 (o, o') en 2 =t 

-.( 0 ', 0 ) en 2 , 

6. n 3 = ( u {U0)})\J 

Veeni / 

U {fc(0i,0 2 )}] U/r(«3). and 

($1 5^2 ) £ H-2 / 

7. n 4 c n 3 3 

(a) |n 4 | = ^population ^nd 

(b) [ o ! £ n 4 ,0 2 £ n 3 \n 4 ] =* f^t( 0 i) < f tes t(o 2 ), 

then I'Pstep S (n, g) = II 4 . 

The G-algorithm for solving a Type-G problem is an 
evolutionary-search algorithm specified as follows: 

Algorithm 4 (G-Algorithm Specification): 

Given: 

• 9= (6, 7, V, T, a, fr, /test, fm, fc, 7r) £ G 

Perform the following steps: 

1. Letn = f r ( £ aX 

\ jG{l,...,len(a:)} / 

2. (a) Let IT = W ste ps(n, g). 

(b) Find n' £ IT 9 £ £ IT => /test(C) > f tastin' )■ 

(c) Set 7 r = tt' . 

(d) setn = ir. 

(e) If ft (n) < 1 + r or runtime exceeds v, then exit, 
returning the value 7r; otherwise, go to step 2a. 

When the G-algorithm is executed to solve a Type-G prob- 
lem g = (8, 7, v , t , a, f T , /test , fm, fc, tt) £ G, the result is 
that tt has been set equal to the optimal solution for the prob- 
lem scenario 7 £ 6. This optimal solution is calculated given 
a, the vector of the values of the Type-G problem’s internal 
parameters (where a different choice of their values would 
generally result in a different solution for the problem sce- 
nario 7). 
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11.3.1. Execution of a G-algorithm 

Executing the G-algorithm (Algorithm 4) for a given Type-G 
problem 

g = (8, 7 , v, r, a, / r , /test, /m, /c, t r) £ G 

consists of performing the prescribed steps given in the speci- 
fication of Algorithm 4 and capturing the final value returned. 


is a Type-G problem of finding an optimal solution for a 
given problem scenario 7 in target problem domain S. Then 
there is a “meta” problem domain S' and a “meta” problem 
scenario 7 ' £ 8' for finding the optimal choice of the values 
of the internal parameters of g, and this problem is solved as 
another Type-G problem 


9' = (<*', V, v', T <*', /r, /test, /m, /c, Y) £ G 


Definition 139 (Function to Execute the G-algorithm (Algo- 
rithm 4)): 

/g-execute : G v 0 3 

Vff = (8, 7, I/, T, a, fr, /test, /m, /c, 7t) £ G, 

if 7T is the optimal solution for problem scenario 7 as re- 
turned from a run of the G-algorithm (Algorithm 4 (page 53)) 
against the Type-G problem g, 

then /g-execute (ff) = 7T. 

Note the implicit dependency on the computing resources: 
the quality (that is, the fitness) of the output result n will, 
in general, be improved through the use of a more power- 
ful computing platform. 

11.4. The G # Problem 

Having described the general problem domain of Type G and 
an algorithm by which to find optimal solutions for Type-G 
problems, we proceed along the line of deliberation indicated 
in the introduction (Subsection 11.1.1 (page 49)). That is, we 
proceed to describe methods, algorithms, and processes by 
which 

1. a Type-G problem may be optimized (thus assuring the 
maximum performance of the G-algorithm itself), and 
by which the Type-G problem of doing this can be opti- 
mized, and, again, by which the Type-G problem of do- 
ing that can be optimized, etc., indefinitely (which is 
referred to as the G : problem), and 

2. a mechanism (the G^ algorithm) can be derived by 
which all of the problem scenarios in a given Type- 
G problem domain may be solved with maximum ef- 
ficiency. 

These additional optimization methods depend on the 
concept of a Type-G meta problem. 

11.4.1. Regarding Type-G Meta Problems 

Importantly for our purposes, the G-algorithm specification 
(Algorithm 4 (page 53)) applies not only to finding an opti- 
mal solution for a given target problem of Type G, but also to 
optimizing the Type-G problem itself. Suppose that, by Def- 
inition 136 (page 53), 

g = (8, 7, *7 T, Ck, f r , /test, fan /c, tf) £ G 


The remaining elements of the tuple g' are to be consistent 
with Definition 136 and must satisfy certain additional con- 
ditions that will be described below. 

11.4.2. Meta-Problem Scenarios Compounded 
Indefinitely 

Consider (as suggested above) an infinite sequence of Type- 
G problems whose first element is g, a Type-G problem of 
deriving the optimal solution of some Type-G problem sce- 
nario 7 , where each element after the first element of the se- 
quence is formed as the Type-G problem of optimizing the 
choice of the values of the internal parameters of the preced- 
ing Type-G problem in the sequence. This idea, designated as 
the G' problem, will, as in the S' problem, entail evolution- 
ary search technology (genetic algorithms) by which to reach 
solutions. 

Given a Type-G problem g in the infinite sequence men- 
tioned above, the successor Type-G problem, g ' , represents 
the task of solving the Type-G meta problem of optimizing 
the choice of the values of its predecessor’s internal param- 
eters. The problem scenario for g' would be a data structure 
that stipulates the requirements and constraints applicable to 
the solution of the Type-G meta problem (and this data struc- 
ture would be in one-to-one correspondence with the data 
structure that represents the internal parameters of g). One 
possible such requirement/constraint would be that the value 
of a, some given internal parameter of g, should fall in some 
particular range (a > 10, for example). Meta-problem sce- 
narios and internal parameters is the subject of the next sub- 
section. 

We might contemplate a method by which to address the 
entire composite problem that consists of (a) optimizing the 
solution of the initial Type-G problem and (b) optimizing the 
solution of the meta problems in the infinite sequence men- 
tioned above. In pursuing this, we would naturally confront 
the question of whether it makes sense to try to apply such 
a search algorithm or method indefinitely to an infinite se- 
quence of problems of Type G as describe above. 

11.4.3. Approaching the (P Problem 

This is moot, however, since in fact we seek not a theoreti- 
cal solution for this entire indefinitely compounded problem. 
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but rather a feasible means of attacking a useful part of it. 
We alluded to a similar issue in the last paragraph of Sec- 
tion 6 . 1 (page 37), and indicated that, in avoiding a kind of 
infinite regression, a justifiable and workable approach — 

1 . would first generate a set of data cases for 

the problem represented by the first element 
9 = (S, 7 , 0 T , a , fr, /test, fm, fc, 7r ) £ G of the 

sequence. Each of the data cases would consist of 

(a) an actual or realistic problem scenario 7 ' £ <5 and 

(b) the calculated optimal choice of the values of 
the internal parameters of the Type-G problem 
for solving the problem scenario 7 ', where the 
optimal choice is discovered via an appropriate 
probabilistic search strategy (i.e., an evolutionary 
search strategy), and 

2 . would then use a hypersurface-fitting method to fit to 
the generated data cases an estimation function that, 
given an arbitrary problem scenario 7 ' belonging to the 
Type-G problem domain <5, would return an estimate of 
the optimal choice of the values of the internal parame- 
ters Of g l = (S, 7 ', V, T, a , f T , /test , fm, fc, 7t) G G. 

The first part of the above approach is satisfied through 
the application of appropriately defined instances of a search 
algorithm — which will be specified below as an evolution- 
ary search algorithm. The second part of the above approach 
is satisfied through a generalized version (the G^ algorithm 
(see Subsection 11.5 (page 58))) of the methods and algo- 
rithms described in Section 7 (page 40). (See Revisions and 
Changes Digest item 27, page 67.) 

11.4.3.1. Internal Parameters of Type-G Problems 

Each internal parameter 

ai,i £ {1, . . . ,len(a)} 

of Type-G problem (5, 7 , v, r, a, f r , /test , fm, fc, tt) has an in- 
teger value that represents the number of new candidate so- 
lutions that will be added to the working population in each 
step respectively in each iteration of the steps listed in the 
definition of a G-algorithm (Algorithm 4 (page 53)). Since a 
problem scenario 7 ' for meta problem S' is a vector of con- 
straints on the solutions of the meta problem (that is, con- 
straints on the values of the internal parameters of the given 
Type-G problem), it may, without loss of generality, be as- 
sumed that all problem scenarios for all meta problems are 
identical, and further that every such constraint is simply that 
the value of the internal parameter must be nonnegative. In 
fact, this assumption will align with the proposition stated 
elsewhere that the constraints represented by a problem sce- 
nario should be as loose as possible so as to ensure the most 
thorough possible exploration of the solution space by the 
evolutionary search algorithm. 


11.4.3.2. Constructing Type-G Meta Problems We now 

define a function that, given a problem scenario 7 in Type- 
G problem domain S, returns the Type-G meta-problem sce- 
nario Y in Type-G meta-problem domain S', i.e., the problem 
of finding an optimal choice of the values of the internal pa- 
rameters of g (the Type-G problem of finding an optimal so- 
lution for the given problem scenario 7 ). 

Definition 140: 

F„ew. g : 0 x G -£ G 9 

V(0 £ , g = (6, 7 , i/, r, a, f T , /test, fm, fc, *)) £ 

0 x G, 

Fnev/-g(Q,g) = (S, 7 , v , T,0, f r , /test, fm, fc, 7r )- 

f ncw -g, given a Type-G problem g and a vector 9 representing 
a choice of the values of the internal parameters of g, returns 
a new Type-G problem identical to g except that c/’s internal 
parameters are replaced with 9. Note that 0, the set of all per- 
missible solutions for problems of Type G, includes permis- 
sible solutions for Type-G meta problems, and thus, a vector 
9 £ N lc "'"£ representing a choice of the values of the inter- 
nal parameters of g, and representing, therefore, a permissi- 
ble solution of the Type-G meta problem, belongs to 0. 

Definition 141: 

ZviETA CG G 9/ £ 0MF. T A =>- 

Vff = (<5, 7, 0 T, a, fr, /test, fm, fc, 7t) € G, 

9' = (<*', Y, ,T' , Of, ft, f( est , f^, ft, 7 O = f(g) <S=> 

1 . <5' is the meta problem of optimizing the Type-G prob- 
lems for solving problem scenarios in 5, 

2. Y £ S' is the meta-problem scenario of optimizing g, 

3 . t' = T, 

4. f r £ Gandmnsdection (S ,7 ), 

5 ■ /test = /test 0 /g-execute ° Gnw-g- 

6 - f m £ Gnutiition (S ,7 ) , 

7. ft £ Crossover Y)- 

A function / that belongs to the set Emeta will accept as in- 
put a Type-G problem g and return as output another Type-G 
problem for solving the meta problem of finding an optimal 
choice of the values of the internal parameters of g. 

A number of observations apply to the above definition 
in relation to its complexity, particularly as to its use in opti- 
mizing a G : problem as described below (Subsection 1 1.4.5). 
The complexity arises mainly from the definition of the fit- 
ness function / t ' es t , which is the composition 7 of three other 
functions. In the Type-G meta problem g' , the fitness func- 
tion / t ' est is defined as c/’s fitness function, f test , applied to the 


7 In mathematics, “function composition” (indicated by the symbol o) 
refers to the use of the output of one function as the input for another. 
See Definition 14 (page 19). 
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optimal solution obtained by executing Algorithm 4 against 
the modified version of g, i.e., the version of g obtained by 
replacing the existing choice of the values of g’s internal pa- 
rameters, a, with 9, the given candidate choice of the val- 
ues of the internal parameters of g. Thus, since the execution 
of Algorithm 4 against the modified version of g takes place 
during the process of running the fitness function of the Type- 
G meta problem, this fitness function does the heavy lifting 
in executing Algorithm 4 against a Type-G meta problem, as 
will be explained in Subsection 1 1.4.5. 

While the insight gained in Section 10.5 (page 49) into the 
effect of changing the value of any given internal parameter 
may be relevant to Type-G problems, we do not pursue the 
confirmation of the relevance by modeling the performance 
of the G-algorithm (Algorithm 4). Instead, it can be noted 
that a direct approach would consist of the immediate appli- 
cation of some / £ Tmeta, where, V<? £ G, the optimal 
choice of the values of the internal parameters of g is sim- 
ply 

/g-execute (/ (<?) ) 

An extension of this approach will be described in Subsec- 
tion 1 1.4.5 relative to a chain of Type-G meta problems. 

11.4.4. The G : Problem: A Chain of Type-G Meta 
Problems 

We proceed to consider the generalization of the concepts 
addressed in the main body of this paper, namely, the prob- 
lem of (1) how to choose the values of the internal param- 
eters of the Type-G problem to maximize the performance 
of the G-algorithm in a fielded system, (2) how to optimize 
the internal parameters of the Type-G problem of optimizing 
that Type-G problem, (3) how to optimize the Type-G prob- 
lem that does this, etc., indefinitely. We refer to this problem 
as the G : problem. Note that its rather abstract underlying 
idea will not preclude a treatment of the G : problem support- 
ing practicality and feasibility. 

Definition 142 (G** Problem): 

G* C E*(G) 9 £ £ G* =► 

1. 3g £ G B g = £ 0 , 

2. 3/ £ Fmeta 3 

Vj£{ l,...,len(0-l},& = /(£,-i) 

G* is the set of all possible G : problems. Each element ex- 
cept the first element of the sequence £ £ G* is a Type-G 
meta problem of optimizing its predecessor. £ 0 , the first el- 
ement of £, is a Type-G problem representing the base case 
for the recursive process that takes place when one of its suc- 
cessors in £ is solved. By Definition 136, £o represents some 
Type-G problem g = ( 6 , 7, v, t, a, f r , / tcst , / m , /c- tt) G G 
for finding an optimum solution for problem scenario 7 £ 6 . 


11.4.5. Optimized G : Problem 

Definition 143 (Optimized G : Problem): 

A G : problem £ £ G* is said to be optimized if and only 
if Algorithm 4 has been run against the Type-G meta prob- 
lem £ien(f)— 1 , resulting, recursively, in the replacement, in 
Type-G problems £j, j £ {0, . . . ,len(£) — 2}, of the val- 
ues of their internal parameters with the optimal values com- 
puted by recursively executing Algorithm 4 against each ele- 
ment of £ starting with its last element (£i e n(j)-i)- 

11.4.5.1. Explanation of Recursive Optimization in the 
G Problem Algorithm 4 is recursive by virtue of the defi- 
nition of the fitness function of a Type-G meta problem (see 
remarks under Definition 141). This fact enables the opti- 
mization of the G : problem, where the entire chain (i.e., 
sequence) of Type-G meta problems described in Defini- 
tion 142 will be optimized by application of the algorithm 
to the last element of the chain. 

By way of further explanation, note that some prescribed 
function / £ -Fmeta, given some element £,; in the chain (se- 
quence) £ as input, will have produced the Type-G meta prob- 
lem 

£,;+l = {S','/, u',T',a', /', / t ' est , f m , /', TT 1 ) 

for optimizing £,. By Definition 141, 7 ' £ S' is the meta- 
problem scenario of optimizing target Type-G problem £,;. 
Applying Algorithm 4 to £j + i will take the following course: 

1. Step 1 executes the random-selection function /' and 
returns ft, a set of candidate solutions of problem sce- 
nario 7', the problem of optimizing the choice of the in- 
ternal parameters of Type-G problem £, . Thus, II is a set 
of vectors representing possible such choices, i.e., solu- 
tions of problem scenario 7'. 

2. Step 2a executes the function W£teps with the ordered 
pair (II, £j + i) as input and then sets 11' to the value re- 
turned. As Wsteps executes, the composite function / t ' est 
will be used to test the candidate solutions individu- 
ally. Since by Definition 141, / t ' est executes the func- 
tion /g.execute with the Type-G problem £,; as the input, 
then, by Definition 139, Algorithm 4 will itself be in- 
voked again part-way through the steps of the self-same 
algorithm, thus resulting in recursion. 

Step 2 of Algorithm 4 progresses through successive gen- 
erations of candidate solutions, ultimately ending with either 
the expiration of the allowed run time v' or the discovery of 
a “good enough” solution according to the parameter t', and 
the best solution found during this iterative search process is 
returned at the termination of step 2 . 

It may be helpful to elaborate somewhat on the use, in the 
definition of the G : problem (Definition 142), of the function 
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f £ ^NIKTA. which, in constructing £, produces, for each el- 
ement the Type-G meta problem £ ?+1 that will be solved 
via Algorithm 4. The key part of the definition of f £ Fmeta 
is the composite function / t ' est . When invoked during the ex- 
ecution of the function Wsteps against the set II of candidate 
solutions, / t ' est first applies the function F new . g to the candi- 
date Type-G problem given as input along with the candidate 
solution (a choice, n (see step 2b of Algorithm 4), of the val- 
ues of the Type-G problem’s internal parameters), producing 
as output a modified version of the target Type-G problem, 
with 7 r in place of the original vector a of internal parame- 
ters. This output from F„ ew - g (he., the modified version of the 
target Type-G problem) is used next (according to the defini- 
tion of /( CSt as the composite function / test o f g . eKecute o F new _ g ) 
as input to the function / g _ eX e cute, whose output (the optimal 
solution returned from running Algorithm 4 against the mod- 
ified version of the target Type-G problem) is used as input to 
the fitness function / tes t, which is the fitness function of the 
target Type-G problem itself. 

But the recursive nature of Algorithm 4, when used on a 
member of a chain of Type-G meta problems, means that the 
above sequence of operations continues until the base case 
is reached in the chain (i.e., the first element of the chain), 
where the target Type-G problem, by the definition of a G 1 * 
problem (Definition 142), is not a Type-G meta problem (i.e., 
the problem scenario is not to optimize a predecessor in £) 
and, in completing the recursive process, the fitness of the so- 
lution returned from applying Algorithm 4 against it is used 
in following in reverse order the progression of operations 
that took place in the recursive chain ending at the base case. 

11.4.5.2. Limits on Run Time Optimizing a G : problem 
£ £ G*, involving recursion during the execution of Algo- 
rithm 4, in which each new recursive step involves the full 
evolutionary search process that itself is a repetitive process 
of evolving a population of solutions through perhaps many 
generations, is easily seen to be very demanding computa- 
tionally — the more so the longer the sequence £. 

From an implementer’s point of view, an early question 
would concern how much run time to allow for the optimiza- 
tion of £ (see Definition 143). That is, suppose i £ N + is the 
index of a Type-G meta problem in £, and 


in the case of a G* -problem optimization. Thus, if 

£o = 9 = (S, 7, v, r, a , / r , /test, /m, /c, n) £ G 

(where v, the run time of g (or at least its typical value), will 
also be learned from experience) then the run time expected 
for the execution of the Type-G meta problem £, will be given 
by the relation 

v ' = k len l/ (9) 

Hence, given the simplifying assumption that each evolu- 
tionary search will (with fixed computational resources) pro- 
cess fc gen generations before reaching the optimal solution, 
the conclusion is that the computational burden increases ex- 
ponentially with the size of the G : problem £ £ G* (i.e., ex- 
ponentially with the length of £). 

The assumption regarding fc gen could be modified to re- 
flect that undoubtedly the “typical” number of generations 
for the runs of the application program varies as a function 
of the index i into the sequence £. That is, fc gen : N — > N. If 
we now consider that the allowed run time is a sequence v 
(where = £,; [3] ) we can restate Equation 9: 

*7+1 ^gen(4 T 1)*7 (10) 

(See Revisions and Changes Digest item 29, page 67.) 

Despite the fact that no principles support the a priori 
choice of an optimal vector of the values of the internal pa- 
rameters of the base case (i.e., for the Type-G problem £o), 
we must allow for the possibility that Type-G meta problems 
may all have the same optimal vector of the values of their in- 
ternal parameters. In this circumstance, after computationally 
establishing this optimal vector for £i, it would render unnec- 
essary any further computation to optimize any of the subse- 
quent Type-G meta problems in £. Therefore, the question 
of run-time limits becomes moot in this circumstance, but 
whether this circumstance actually prevails in general would 
have little chance of resolution short of experimentation, and 
so in the meantime it must be categorized as speculative. 

Such experimentation could hardly be conducted in the 
first place upon any assumption other than the one repre- 
sented by Equation 10 (absent any theoretical or a priori 
knowledge to the contrary) and thus is established the use- 
fulness of the foregoing analysis. 


£i = (S', V, l/, t', a', f T , /t' est , /m, /', /) 


11.4.6. Practical Stopping Point in the G : Algorithm 


Then what value should i/ (i.e., £,; [3] j have? 

Experience with an evolutionary-search application for a 
given problem domain will eventually teach the practitioner 
the empirical fact that runs of the application will process 
some typical number k gen of generations before reaching the 
optimal solution. For argumentation purposes, we assume 
that the idea of the existence of such a typical value applies 


As indicated previously (Subsection 11.4.3 (page 54)), how- 
ever, the purpose of having an optimized G : problem is not 
to have some lengthy sequence of Type-G meta problems op- 
timized, for which the necessary computational power would 
(as shown in the foregoing paragraphs) increase exponen- 
tially with the length of the sequence. Indeed, reflecting the 
author’s judgment, the requirement for practical operational 
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use would be much more modest (see further remarks in 
Paragraph 11.5.1.3), and would afford adequate advantage 
with the sequence £ having length 2, with a single Type-G 
meta problem 0 to optimize the Type-G problem £o for solv- 
ing a given target problem scenario. Thus, executing Algo- 
rithm 4 against Type-G problem 0 would optimize the in- 
ternal parameters of the Type-G problem £q, supporting the 
practical approaches to be described next for the use of the 
above G : method and algorithm. 

11.5. Overall Optimization: Problem 

11.5.1. The Final Issue 

The final issue to be addressed relative to the generalization 
of the concepts covered in the main body of this paper per- 
tains to the practicality of the G : method and algorithm for 
operational use. 

11.5.1.1. Internal Parameters Estimation Functions 

Various relevant considerations were presented in Sec- 
tion 7 (page 40) in discussing approaches for obtaining 
efficient estimation functions. In the present context, an es- 
timation function, given a problem scenario, would return 
an estimated optimal choice of the values of the inter- 
nal parameters of the Type-G problem for solving the 
given problem scenario. (In the earlier discussion, the con- 
text was the NASA space-data communications scheduling 
problem, whereas here we are in a more abstract discus- 
sion of optimization of a Type-G problem.) 

11.5.1.2. Concerning the Goal As in Section 7 (page 40), 
our goal in the present section is to maximize the practicality 
of the overall general optimization methods implemented in 
fielded systems. We address the problem, which we will refer 
to as the G^ problem, of devising a means for efficiently esti- 
mating an optimal choice of the values of a Type-G problem’s 
internal parameters for any given new problem scenario so 
that it will not be necessary each time to use the G : algorithm 
to perform the whole iterative (and computationally expen- 
sive) process of solving the internal parameter optimization 
problem. Clearly, the overall optimization problem is compu- 
tationally very demanding, and consequently the method and 
algorithm described above for solving the G : problem would 
not be advantageous to use operationally for every new prob- 
lem scenario. (To be sure, such a burdensome strategy would 
quickly be seen to be counterproductive, since an optimal so- 
lution for the given problem scenario would be reached any- 
way during the very first iteration of the effort to solve the 
G : problem, thus obviating any additional effort in that di- 
rection.) However, the G : method and algorithm will support 


the goal of solving the G :: problem of deriving an estima- 
tion function that, given an arbitrary problem scenario for the 
given target problem domain 5 6 A, would, at low cost, re- 
turn an estimated optimal choice of the values of the inter- 
nal parameters of the Type-G problem for solving that prob- 
lem scenario. The objective, then, is to specify an estimation 
method/algorithm that uses (abstracted and computationally 
inexpensive) information about the given problem scenario 
itself. 

11.5.1.3. A Judicious Stopping Point Although the 
method and algorithm specified above for addressing the G : 
problem £ £ G* (see Definition 142) allowed for any ar- 
bitrary number of Type-G meta problems listed in the 
sequence £, the author considers (as indicated in Subsec- 
tion 11.4.6) that, for practical operations using the meth- 
ods and algorithms disclosed herein, the length of £ 
would be 2, so that Type-G problem 0 (i.e., the last ele- 
ment of £) would be the Type-G meta problem for optimiz- 
ing £o for solving the initial problem scenario £o [ 2 ] (note 
that £o is a tuple, whose second element, £o[ 2 ], is a prob- 
lem scenario 7 ). Indeed, upon practical considerations of 
computational feasibility as opposed to purely theoret- 
ical considerations, it is unlikely that any value greater 
than 1 for the index into £ could be entertained at all, and 
so in this sense the G : algorithm is academic. In the dis- 
cussion that follows, it will be included in the process 
for implementing the G^ algorithm, with the understand- 
ing that, in use, there would be only one level of Type-G 
problem optimization (corresponding to a single applica- 
tion of Type-G problem optimization) representing a kind of 
minimal use (and perhaps the only feasible use, as will be ex- 
plained) of the G : algorithm). 

The question of the efficiency of the Type-G problem- 
optimization process would itself involve the question of how 
to set the values of the internal parameters of 0, the Type-G 
meta problem for solving the meta-problem scenario 0 [ 2 ], 
This is an open question, although, since all of the Type- 
G meta problems have identical problem scenarios (i.e., all 
of the constraints they specify are, by assumption (see Para- 
graph 11.4.3.1), the same), it cannot be dismissed that (as dis- 
cussed in Paragraph 11.4.5.2) the optimal choice of the val- 
ues of the internal parameters of all of the Type-G meta prob- 
lems would be the same or at least nearly the same. Whether 
a substantial improvement in performance might occur for 
small changes in the values of the internal parameters is not 
known, but seems unlikely over a wide range of possible 
choices; in other words, performance may be insensitive to 
the choice. In that case, the effort to optimize the Type-G 
meta problems listed in £ would have a correspondingly low 
practical justification. As to what should be the actual (op- 
timal) choice of the values of the internal parameters of a 
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Type-G meta problem, there would be little a priori guidance 
that could be offered to a developer beyond that afforded by 
Appendix A (page 44) combined with trial-and-error experi- 
ence. (See Revisions and Changes Digest item 28, page 67.) 

11.5.1.4. Challenges From the Real World It should be 
well noted that real-world problem domains of Type G typ- 
ically entail significant complexities that inevitably would 
translate into challenges in using the methods presented in 
this appendix. An estimation function as described above, 
even if derivable in principle, may be difficult to obtain 
within realistic limits on computing resources (see also the 
remarks in Section 7.4 (page 41) and Subsection 11.4.6 
(page 57)). 

The approaches to be described for solving the G :: prob- 
lem will produce results (i.e., will produce instances of es- 
timation functions), but the approaches assume a selection 
of real-world input data to which, in effect, a model will 
be fitted (see the outline of the approach given in Subsec- 
tion 11.4.3 (page 54)). The accuracy of the derived estima- 
tion functions will be directly related not only to the shrewd- 
ness of the choices that determine the form or architecture 
of the model, but also to the selected input data (the train- 
ing data) to which the model will be fitted, i.e., the number 
of precomputed data points and their distribution across the 
solution space. The required accuracy of the derived estima- 
tion functions may dictate a significant number of precom- 
puted data points, and correspondingly significant comput- 
ing resources [24]. 

Further, since the accuracy metric undoubtedly would ex- 
hibit asymptotic behavior in relation to the number and dis- 
tribution of precomputed data points, and since the asymp- 
tote is not known in advance, even more computation would 
be needed to gain the assurance of any prescribed accu- 
racy. Thus, the real-world challenges in using the methods 
to be described would be considerable. However, the meth- 
ods can be expected to achieve the objective mentioned in 
Paragraph 11.5.1.2 (page 58) given a reasonably tame rela- 
tionship between the independent variable (the problem sce- 
nario (or rather its characterization (see Paragraph 11.5.1.5))) 
and the dependent variable (the optimal choice of the values 
of the internal parameters of the Type-G problem for solv- 
ing the problem scenario). The tameness of this relationship 
may be expected to be target-problem dependent, but an in- 
dependent means of determining the tameness in advance is 
unknown — although, reasonably, some probabilistic method 
would be strongly indicated (if not unavoidable). 

11.5.1.5. Characterization Functions The approaches 
described in Section 7 relied upon the concept of a 
problem-scenario characterization function — which is a con- 


cept also involved in the approaches described in the fol- 
lowing paragraphs concerning mechanisms for estimating 
optimal choices of the values of the internal parame- 
ters of Type-G problems. The characterization function is 
intended to be a computationally inexpensive means of dis- 
tinguishing between problem scenarios in terms that are 
relevant to the efficiency of the evolutionary search meth- 
ods that will be used in solving arbitrary problem scenarios 
in the given Type-G problem domain. The efficiency of the 
search methods that we disclose herein is related to (among 
possibly many other things) the sizes of the data struc- 
tures that represent the elements of the problem scenario: by 
Definition 123 (page 50), a problem scenario is a finite se- 
quence each element of which is a finite data structure. In the 
case of the problem domain of scheduling space-data com- 
munications (see Section 7 (page 40)), each of these data 
structures was a set, and the sizes of all of the data struc- 
tures listed in a given problem scenario were used as the 
elements of the vector returned by the characterization func- 
tion (Definition 122 (page 40)). Partly for reasons of 
tractability and operational efficiency, we elect to use a simi- 
lar scheme here. 

We proceed by specifying, in the context of Type-G 
problem domains, the concept of a problem scenario- 
characterization function, noting from Definition 128 
(page 50) that, for a given target problem domain 5 of Type 
G, there exists a positive integer k p = Adi m (<5) such that 
all problem scenarios 7 £ <5 have length k p , and, thus, ev- 
ery problem scenario 7 £ 5 has a A: y) -dimensional characteri- 
zation 

c € N fep 

For the problem, the characterization was defined so that 
Vj £ {1 , ,k p },Cj was the size of the finite data structure 
7 j (see Definition 122 (page 40)). For the generalized prob- 
lem of Type G, the definition of the characterization func- 
tions must be somewhat generalized and must accommodate 
Type-G meta problems. 

Definition 144 (Problem-Scenario-Characterization Func- 
tion for Given Problem Domain): 

A: A — 9 

V<5 £ A, A £ A (S) => V 7 £ S, A(<5, 7 ) £ N Adi ”W 

A(5) returns a set of characterization functions for the prob- 
lem domain 5. 

11.5.2. Regression Methods for Solving the G :: Problem 

Deriving an estimation function /estimation that returns an es- 
timate of the optimal choice of the values of the internal pa- 
rameters of a Type-G problem may be accomplished through 
the application of some form of regression technology [16]. 
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(Use of the term “regression” herein is intended to encom- 
pass the general category of regression-analysis technolo- 
gies.) (See Revisions and Changes Digest item 32, page 67.)) 

The estimation function to be derived is imagined (with 
the risk of oversimplification) as a hypersurface whose do- 
main (consisting of the values of the independent variable) is 
the set of all possible problem scenarios (or, rather, their char- 
acterizations) and whose codomain (consisting of the val- 
ues of the dependent variable) is the set of estimated optimal 
choices of the values of the internal parameters of the Type-G 
problems for solving problem scenarios in target problem do- 
main 5. An applicable modeling approach as identified above 
represents a kind of hypersurface-fitting technique, as men- 
tioned in the discussion in Subsection 7.2 (page 40), which 
concerned a method for scheduling-algorithm optimization. 

It should be reiterated that applying any regression tech- 
nology would be subject to cautions similar to the ones stated 
earlier (Subsection 7.4 (page 41) and Paragraph 11.5.1.4 
(page 59))). 

Regardless of which regression technology is employed, 
the derived estimation function would have value in an op- 
erational system in terms of maximizing the performance 
of the G-algorithm. For any given problem scenario to be 
solved by the system, the values of the internal parameters of 
the Type-G problem would first be adjusted according to the 
estimate that would be generated by the derived estimation 
function. The process for using the derived estimation func- 
tion operationally will be further specified in Subsection 11.7 
(page 64). 

The objective of applying a regression technology to a G^ 
problem is to derive an estimation function /estimation from a 
given known data set Q C Dq, where for each (c, e) £ Q, c 
is a characterization of a problem scenario and e is a corre- 
sponding calculated optimal choice of the values of the inter- 
nal parameters of the Type-G problem for solving the prob- 
lem scenario. 

11.5.3. Functions That Model a Given Data Set 

It is assumed that a regression-analysis technology will have 
been selected for application in solving G^ problems. Solv- 
ing a given G^ problem would consist of applying the se- 
lected regression analysis technology to an appropriate pre- 
computed data set Q to derive a function that models Q. The 
derived function may then be used to estimate the value of 
the dependent variable for any given value of the indepen- 
dent variable. The value of the independent variable for a 
given G^ problem would be a tuple representing the char- 
acterization of the given problem scenario, and the value of 
the dependent variable would be a tuple representing the es- 
timated optimal choice of the values of the internal param- 


eters of the Type-G problem for solving the given problem 
scenario. 

Definition 145 (Set of Regression Analysis Technologies): 
A r = {a: a is a regression-analysis technology}. 

It will be understood that regression-analysis technology 
a re gr £ A r has been selected for use in solving G :: prob- 
lems. 

Definition 146 (Functions That Model a Given Data Set): 

A function / £ Dq° is said to model Q C Dq if and only 
if / has been derived through the application of regression- 
analysis technology a regr to Q and 

(c,e) £ Q => /(c) = e 

Note that / in the above definition is a subset of Dq. (See Re- 
visions and Changes Digest item 30, page 67.) 

Definition 147: 

T : p(Dq) — > Dq° 9 MQ C Dq, T(Q) is a model of Q 
derived by applying regression-analysis technology a regr to 
the data set Q. 

Thus, if T(Q) models Q, then V(c, e) £ Q, T (Q){c) = e. 

Definition 148 (Training-Data Sets): 

D: Ax p(r) x codomain(A) -> p(p(Dg)) 9 

B C 5, A G A(<5)^ e Ax p(F) x codomain(A), 

VQ £ D(S, B, A), (c, e) £ Q => 

37 £ B and 3 optimized G : problem £ £ G* 9 

1- Co = (6,7! •>•>“) •>•)•>•)•) £ Gscenario(<5,7), 

2. c = X(S, 7 ), and 

3. e = a = £o[5] 

(See Revisions and Changes Digest item 31 (page 67).) 

The function D returns the set of all possible training-data 
sets for G : " problems (to be described in the next section). 
Each such data set Q will be assumed to comprise actual 
calculated data. Each member of Q, then, is an ordered pair 
(c, e), where c is the calculated characterization of some re- 
alistic/actual problem scenario drawn from the given set B, 
and, for a corresponding G : problem £ that has been opti- 
mized by running Algorithm 4 (page 53) (see Definition 143 
(page 56)), e is the optimal choice of the values of the inter- 
nal parameters of the Type-G problem £q. It is assumed that 
each such training-data set Q can be modeled by applying to 
Q the selected regression-analysis technology a regr - The de- 
rived model is identified as an estimation function that, given 
the characterization of an arbitrary problem scenario 7 in the 
given problem domain <5, will return the estimated optimal 
choice of the values of the internal parameters of the Type-G 
problem for solving 7 . 
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11.5.4. The G n Problem 

Definition 149 (G^ Problem): 

A tuple 

(<Se A,BCS,\G A(<5) j /estimation^ 

is said to be a problem if and only if 

1. each member of B is an actual/realistic problem sce- 
nario, 

2. 3Q £ D(6,B,\)l 

./estimation — T (Q). 

11.5.5. The Algorithm Employing 
Regression-Analysis Technology 

The essential steps in applying a regression-analysis ap- 
proach in the G : ® problem are as follows: 

Algorithm 5 (G^ Algorithm Employing Regression Analy- 
sis): 

Given: 

• SeA, 

• B C S is a set of actual/realistic problem scenarios se- 
lected from the set S, 

. AeA(tf). 

(Note: The results of running an implementation of the 
present algorithm are highly dependent on the num- 
ber and distribution of the scenarios in the training-data 
set B. If the accuracy of the estimation function gen- 
erated by the implementation is not deemed adequate, 
then these scenarios would need to be revised to im- 
prove their solution-space coverage and used in a fresh 
rerun.) 

Perform the following steps: 

1. Let Q £ D(5,B,X). 

2. Perform regression analysis using the training-data set 
Q, resulting in the determination of a function that best 
fits the members of Q. That is, let /estimation = T (Q). 

3. If step 2 (the regression-analysis step) succeeds, then 
form the G :; Problem 

(5, B , A, /estimation) 

and exit indicating success. If regression analysis fails, 
then exit indicating failure, calling upon the user to al- 
ter the given set B of actual/realistic problem scenar- 
ios (e.g., by increasing their number or variety) (noting 
that this alteration gives an altered G :: problem) and re- 
run the algorithm. 

Step 1 above will, in general, involve significant computation 
of a recursive nature using Algorithm 4 (page 53) to derive 
the data set Q (see Definition 148 (page 60)). 


11.6. Implementation Process 

Implementation of the generalized methods and algorithms 
described in this Appendix may be straightforward (not to 
say trivial) for some problem domains but likely would be 
challenging for others. For the sake of completeness of this 
disclosure, we now delineate a nominal implementation pro- 
cess, which would be applicable to all implementation ef- 
forts, but which does not preclude appropriate variations or 
adaptations for particular cases. 

11.6.1. The Basic Implementation Alternatives 

The minimum implementation effort would have the goal of 
building a system that implements a Type-G problem 

g = (5, 7 , v, r, a, / r , /test, /m, /c, tt) £G 

configured initially with arbitrary (non-optimized) choices of 
the values of the internal parameters a for solving the given 
problem scenario 7 £ 5. A more ambitious possible effort 
would have this minimal implementation as one goal, and 
would have the further goal of implementing a system for 
solving the G : " problem for the same problem domain S £ A. 

In either case, the implemented system will produce opti- 
mal solutions for problem scenarios in the target domain 6. 
The system developed in the more ambitious possible effort 
mentioned above would be expected to perform more effi- 
ciently in the routine operations mode — at the cost of the ef- 
fort to solve the G i: problem to derive the estimation function 
(see Subsection 1 1.5) for estimating, for each given problem 
scenario 7 , the optimal choice of the values of the internal pa- 
rameters of g £ G sce „ario(^, 7 )- 

The general implementation approach that will be de- 
scribed below in detail is first to implement modules sepa- 
rately, and then to integrate those modules, together with all 
other necessary modules (e.g., interfaces with users and an- 
cillary systems), into the overall fielded system, with appro- 
priate testing, documentation, etc. 

11.6.2. The First Implementation Alternative (Basic 
Implementation of the G- Algorithm) 

In the first alternative (i.e., the basic implementation of the 
G-algorithm), the implementation steps follow the first few 
steps enumerated in the G-algorithm specification (Algo- 
rithm 4 (page 53)). A subsystem that is capable of creating 
and solving a Type-G problem 

g = (<5, 7 , v, T, a, /r, /test, /m, /c, n) £ G 

would be constructed by means of the following process: 
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Process 2 (Process for Implementation, First Alterna- 
tive (Basic Implementation for Creating and Solving a 
Type-G Problem)): 

Given: 

• A 

• 7 £ 5 

Perform the following steps: 

1 . Implementation steps for a subsystem for creating a 
Type-G problem for solving 7 £ S. 

(a) Develop a module that supports the cre- 
ation/setting of — 

i. v £ N + , a value that represents the run-time 
limit in units of seconds. 

ii. t £ R, a small nonnegative value to repre- 
sent a policy or judgment as to how close to 
perfect a solution must be (i.e., how close a 
solution’s fitness must be to unity) to be con- 
sidered “good enough” to exit the algorithm. 
This value normally would be small enough 
(0, say) to ensure that the algorithm always 
ran for the maximum allowed run time v. 

iii. a £ Dq, the vector representing the user’s 
initial choice of the values of the internal pa- 
rameters of g, with len (a) = A dim (<5). 

(b) Develop a module that embodies a random- 
selection function f r £ -F randomse iection(£, 7) 

(c) Develop a module that embodies a fitness func- 
tion /test £ Tfitness ( </ 7 ) • 

(d) Develop a module that embodies a genetic- 
mutation function f m £ F mutatioa (6, 7)). 

(e) Develop a module that embodies a genetic- 
crossover function f c £ F cr0SS0V er(A, 7)). 

(f) Develop a module that supports the creation of a 
place-holder data structure 7 r representing an ar- 
bitrary member of 0 scenario ( <5, 7). 

(g) Develop a module that supports the creation of 
the data structure 

9 = (5, 7; *7 T, a , fr , /test, fm, fc, Tt) G 

^scenario (<*> 7) 

according to Definition 136 (page 53) and Defini- 
tion 137 (page 53) 

2. Implementation steps for a subsystem embodying 
Algorithm 4: 

(a) Develop a module that embodies the function 
Wsteps according to Definition 138 (page 53), in- 
corporating the module developed in step lg. 


(b) Develop a module to capture II, the output of 
function f r when given the input equal to 



jG{l,...,len(a)} 

(c) Develop a module to capture IT, the out- 
put of function Wsteps (the module devel- 
oped in step 2a) when given the ordered pair 
(II, <7) as input, where II and g are the out- 
puts of the modules developed in steps 2b 
(for creating a random-selection function 
fr £ F 1 randomselection(<5,7) ( for a given (5, 7)) and 
lg (for for creating a Type-G problem), respec- 
tively. 

(d) Develop a module to find a member tt' £ W B 

C £ n' => /test(C) > /testK), where n ' is the 
set captured by executing the module developed 
in step 2c. 

(e) Develop a module that sets n to the output, tt', 
from executing the module developed in step 2d. 

(f) Develop a module that sets II to the output, II', 
from executing the module developed in step 2c. 

(g) Develop a module that performs the test f t (7 r) < 
1 + t and tests whether the elapsed run time ex- 
ceeds v, and if either test is affirmative, then exits, 
returning the value 7 r, and, if otherwise, then re- 
sumes execution of the sequence of modules de- 
veloped in steps 2c through 2g. 

3. Develop a module that embodies the function /g.execute, 
which in turn will incorporate the module embodying 
Algorithm 4 developed in step 2. 

4. Develop a module that (a) executes, with g £ G as in- 
put, the module embodying the function /g.execute devel- 
oped in step 3 for a given Type-G problem and (b) re- 
turns the optimal solution of g. 

5. Perform system integration and testing of the modules 
developed as specified above, along with all other nec- 
essary modules (e.g., user interfaces). 

Once implemented, the fielded system would be used op- 
erationally according to the following straightforward pro- 
cess: 

Process 3 (Process for Operational Use of Implementa- 
tion Under First Alternative (Basic Implementation for 
Creating and Solving a Type-G Problem)): 

Given: 

• <5 £ A 

• 7 £ 5 
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Perform the following steps: 

1 . Prepare all input data required for a run of the system 
developed in Process 2 (page 62) (including the target 
problem scenario and other inputs as required by the G- 
algorithm specification (Algorithm 4 (page 53))). 

2. Initiate a run of the system with the stipulated inputs 
and capture output upon termination of run. The out- 
put is an optimal solution for the given problem sce- 
nario 7 (see remarks in Section 2.4.7 on page 15 con- 
cerning the concept of “optimum”). 

11.6.3. The Second Implementation Alternative 
(Implementation of the Algorithm) 

The second implementation alternative incorporates all of the 
steps in the first alternative as described above (Process 2 
(page 62)), which produces an implementation of a system 
that can create and solve a Type-G problem 

(S 7, v, r, a, / r , /test, fm, fc, 7r) e G 

The additional steps required in the second implementation 
alternative will be described next, and have the objective of 
maximizing the performance of the fielded system over the 
broad range of possible problem scenarios. This objective 
is achieved by implementing the G : ® algorithm (see Algo- 
rithm 5 (page 61), which incorporates the G : problem opti- 
mization (see Definition 143 (page 56)), which, in turn, in- 
corporates the G-algorithm (Algorithm 4 (page 53)). 

It is necessary, then, to describe implementation steps for 
the G : problem optimization, as well as the G :: algorithm). 

Process 4 (Process for Implementation, Second Alter- 
native (Implementation of G :: Algorithm (Algorithm 5 
(page 61))): 

Given: 

• A 

Perform the following steps: 

1. Implementation Steps for Support-Modules for 
Type-G Problem Optimization. Supporting mod- 
ules in an implementation of a Type-G problem- 
optimization function will be constructed by means of 
the following steps: 

(a) Develop (see implementation steps specified in 
Process 2 (page 62)), or incorporate, a module 
that supports the creation and solving of a Type-G 
problem 

g = (S, 7, V, T, a , f r , /test , fm, fc, M S G. 

Note that this module incorporates (from step 3 
of Process 2) a module that implements the G- 
algorithm-execution function / g . e xe cute (see Defi- 
nition 139). 


(b) Develop a module that embodies the function 
F„ ew -g (see Definition 140 (page 55)) 

(c) Develop a module that embodies the definition of 
a function in the set Tmeta that, given a Type-G 
problem 

9 = {S 7, v , T, a, f T , /test, fm, fc, 7r) S G 

returns a Type-G meta problem g' (see Defini- 
tion 141 (page 55) in Paragraph 11.4.3.1). 

2. Implementation Steps for a Subsystem that Sup- 
ports the Creation of a Module that Embodies the 
G : Problem Optimization. A subsystem that supports 
the creation and optimization of a G : problem f £ G* 
(Definition 142) (where len(£) = 2, in accord with 
the position taken in Subsection 1 1 .4.6 (page 57) and 
in Paragraph 11.5.1.3 (page 58)) will result from inte- 
grating modules constructed by means of the following 
steps: 

(a) Develop or incorporate a module that implements 
the G-algorithm-execution function f g . eX e cute (see 
step 3 of Process 2). 

(b) Develop a module that creates the G : problem 
£ £ G*, with £o = 9, i n accordance with Defi- 
nition 142 (page 56), where 

9 = {$, T, V, T, a, fr, /test, fm, fc, 7r) £ G 
is a given Type-G problem. This module incorpo- 
rates the module developed in step lc, which is 
an implementation of a function in Tmeta, which 
in turn incorporates the module developed or in- 
corporated in step 2a for the function / g . e xe cute- 

(c) Develop a module that incorporates the module 
developed in step 2 of Process 2 and supports 
the execution of Algorithm 4 against the Type-G 
problem £i en (£)-i, which results in the optimized 
version of the G* problem £ £ G* (see Defini- 
tion 143 (page 56)). 

3. Implementation Steps for the G® Algorithm Via 
Regression Analysis. A system incorporating a 
regression-analysis approach for solving a G :: prob- 
lem (6, B, A, /estimation) will be constructed by means 
of the following steps: 

Given: 

<5 £ A 

Perform the following steps: 

(a) Develop a module that embodies a problem- 
scenario characterization function A £ A(S) (see 
Definition 144 (page 59)). 

(b) Develop a module to support the creation of 
a training-data set B C S consisting of ac- 
tual/realistic problem scenarios in <5. 
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(c) Incorporate a module supporting the creation of 
Type-G problems for problem scenarios for the 
given target problem domain S (see step la above 
and Subsection 11.6.2). 

(d) Develop or incorporate a module that em- 
bodies the function D (see Definition 148 

(page 60)), which incorporates the module de- 
veloped in step 2c for optimizing a G : prob- 
lem. 

(e) Develop or incorporate a module that em- 
bodies the function T (see Definition 147 

(page 60)), which implements the regres- 
sion analysis technology a reg r (see explanation 
below Definition 145 (page 60)), and which in- 
corporates the modules developed in steps 3a and 
la. 

(f) Develop a module that executes the module de- 
veloped in step 3e and captures the output (i.e., 
the function /estimation = T(Q), where Q G 

D(S,B, A)). 

(g) Develop a module that 

i. executes the module developed in step 3a 
and retains the function A. 

ii. executes the module developed in step 3b 
and retains the set B. 

iii. executes the module developed in step 3d 
and retains the set Q G D(S,B, A). 

iv. executes the module developed in step 3f 
and retains the function /estimation = T(<3). 

v. if the regression-analysis step 3(g)iv is suc- 
cessful, then constructs the G^ problem 

(5 G A, B C 5, A G A(<S) > /estimation) 
and exits indicating success; otherwise, exits 
indicating failure and calling upon the user 
to start a new run, ensuring that the set B re- 
tained from step 3(g)ii is more appropriate 
in solution-space coverage. 

4. System Integration. Perform system integration and 
testing of the modules developed as specified above, 
along with all other necessary modules (e.g., user in- 
terfaces) for the final fielded system. 

The final result of the implementation steps given above 
would be a system consisting of (a) a subsystem by which 
a Type-G problem can be used to produce optimal solutions 
for any given problem scenario and (b) a subsystem by which 
the optimal choice of the values of the internal parameters of 
a given Type-G problem can be estimated for arbitrary prob- 
lem scenarios to enable the most efficient overall possible op- 
eration of the system for arbitrary problem scenarios. 


For reasons similar to those articulated earlier (Sec- 
tion 7.4 (page 41)), the implementation effort described 
above — which invokes regression-analysis technologies — is 
nontrivial and will necessarily require the involvement of ex- 
perts in the selected regression technology, especially in 
relation to step 3e of Process 4. 

11.7. Estimation Function: Operational Use 

The resulting tested and verified estimation-function imple- 
mentation would become a tool for operational use within a 
fielded system. The routine use of such a tool would involve 
the following process: 

Process 5 (Operational Use of Estimation-Function 
Tool): 

Given: 

• G^ problem 

(S G A, B C 5, A G A(S), /estimation) 

created by running the subsystem that represents 
the implementation of the G :: algorithm and solves 
the given G^ problem (see implementation Pro- 
cess 4, steps 3(g)i through 3(g)v), which results in the 
implementation of an estimation function /estimation)- 

• a problem scenario 7 G <5. 

Perform the following steps: 

1. Compute the characterization c = A(<5, 7 ). 

2. Run the module that creates an implementation of a G- 
algorithm (see Process 2 (page 62)), resulting in an im- 
plementation of 

9 = (6, 7; G T, a, / r , /test, /m, fc, tt) G G. 

3. Capture the estimation function output 

^ = /estimation (c) 

(the estimate of the optimal choice of the values of the 
Type-G problem’s internal parameters for the problem 
scenario 7 ). 

4. Configure the Type-G problem g, replacing a with e: 

ffopt = (/ 7; C G G /r; /test, ,/m ■ ,/c • 7 0 £ 

^scenario (<S, 7)- 

g 0 pt is the optimal Type-G problem for solving problem 
scenario 7 . 

5. Initiate a run of Algorithm 4 (the module developed in 
step 2 of Process 2) against the implementation of g opt 
and capture output upon termination of run. The output 
is an optimal solution for the given problem scenario 7 
(see remarks in Section 2.4.7 on page 15 concerning the 
concept of “optimum”). 
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11.8. Which Regression Analysis Algorithm? 

Interesting (but not necessarily academic) future work 
would, for some selected problem domain, consist of deriv- 
ing an optimal-parameters-estimation function using differ- 
ent regression-analysis technologies and comparing their ex- 
ecution performance. The comparison would be more 
meaningful and reliable if it were based on the same com- 
puting resources and the same training/test data (i.e., the 
same precomputed data cases (see definition of the func- 
tion D (Definition 148), which specifies the set of all 
possible precomputed data sets for a given prob- 
lem)). 


11.9. Final Remarks 

This appendix has described a generalization of the methods 
and algorithms that were specified in the main body of this 
paper, which targeted a specific problem domain (the space- 
data communications scheduling problem). These general- 
ized methods and algorithms are applicable to any problem 
in the very large class of real-world problems that are rep- 
resented by problem domains of Type G (see Definition 127 
(page 50) and Subsection 11.1.3). The specifications of the 
generalized methods and algorithms are sufficiently rigorous 
and complete to support their implementation (as described 
in Section 11.6 (page 61)) as a fielded system that efficiently 
produces an optimal solution for any problem scenario in any 
target problem domain of Type G. 

The G^ problem £ € G* (see Definition 142 (page 56)), 
i.e., the problem of optimizing the Type-G problems and 
Type-G meta problems themselves, was incorporated into the 
G^ problem (i.e., the problem of devising an estimation func- 
tion by which to obtain, for an arbitrary problem scenario, 
an estimate of the optimal choice of the values of the in- 
ternal parameters of the Type-G problem g — it being noted 
that Algorithm 4 (page 53) applied to the Type-G problem g 
solves (i.e., produces an optimal solution for) the given prob- 
lem scenario). For reasons explained in Paragraph 11.5.1.3 
(page 58), the G'-problem optimization algorithm will be 
applied by executing Algorithm 4 against the Type-G meta 
problem £i, resulting in an optimized version of the Type- 
G problem £o = g. The methods and algorithms for solv- 
ing a G #tJ problem (S e A, B C 5, A e A (5) > /estimation) 
(see Definition 149 (page 61)) invoked regression-analysis 
technologies as a means to fit a model (a hypersurface) to a 
set of known data points precomputed using the G : method 
and algorithm, and thereby to derive the estimation func- 
tion /estimation- With adequate computing resources and tal- 
ent, these overall optimization approaches, as specified, can 
be implemented as a fielded system that performs with maxi- 


mum feasible efficiency solving any problem scenario in any 
target problem domain of Type G. 

12. Revisions and Changes Digest 

The following list identifies and recapitulates significant re- 
visions that were included in the present document. 

1. In Subsection 1.1, page 7, the last three sentences of 
the first paragraph replaced the following three origi- 
nal sentences: 

Present operational scheduling capabilities do not 
generate true optimized schedules for reasons that will 
be explained below, but can (when the option is in- 
voked) generate schedules that are free of radio fre- 
quency interference (RFI) effects by blocking out por- 
tions of the problem-solution space from consideration 
whenever those portions appear with any predicted RFI 
effects. Similarly, the current operational scheduling 
system prunes away portions of the solution space upon 
encountering violations of the various other constraints 
that must be satisfied. This approach, which perforce 
ignores large portions of the solution space, necessar- 
ily means that schedule optimization cannot be an ac- 
tual achievable objective of the current scheduling sys- 
tem. 

In the second paragraph, the first sentence replaced 
the following original first sentence: 

Present space data-communications schedulers have 
the capability of algorithmically generating schedules 
using techniques for representing and exploring the 
problem-solution space as either a graph or a tree of re- 
lated sub-solutions. 

The last sentence of the second paragraph replaced 
the following original last sentence: 

NASA’s present operational scheduling system, us- 
ing such standard search methods, is capable of 
producing workable schedules, albeit with certain sig- 
nificant concessions to the compute-intensive nature 
of the search (including certain problem simplifica- 
tions that themselves, even ignoring the performance 
of the search techniques, preclude the possibil- 
ity of true schedule optimization). 

2. In Subsection 1.6, page 9, the third sentence of the 
last paragraph replaced the following original third sen- 
tence: 

But numerous other fields (particularly those related 
to design optimization, and, more broadly, virtually any 
field where solutions cannot be specified directly but 
can be evaluated as to “goodness”) are encompassed 
under the generalized problem of Type G as defined in 
Appendix B. 
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3. In Subsection 2.4.8, page 16, the second sentence of 
the first paragraph replaced the following original sec- 
ond sentence: 

The current NASA scheduling system, based on con- 
structive techniques or graph-search techniques, does 
not incorporate a strategy for constructing solutions that 
will directly optimize these metrics. 

4. After the first paragraph of Subsection 4.2 (page 18), 
two paragraphs of explanatory remarks were inserted 
concerning set-builder notation and the concept of log- 
ical negation. 

5. On page 19, the revised, equivalent definition of o 
(“function composition”) (Definition 14) clarified the 
meaning of the following original definition of o: 

Vf€X Y ,Vg&Z x ,gof & Z Y . 

6. On page 19, the definition of ’’set of all real numbers" 
(Definition 7) was moved so as to precede the definition 
of | • | (cardinality of a set) (Definition 10)), thereby to 
avoid forward referencing. 

7. On page 19, the definition of ’’power set" (Definition 9) 
was moved so as to precede the definition of Op (the set 
of all finite sets (Definition 10)), thereby to avoid for- 
ward referencing. 

8. On page 19, the definition of Z, the “set of all integer in- 
tervals” (Definition 16), was positioned before the def- 
inition of mdint (Definition 17) and replaced the fol- 
lowing original definition of the set of all closed inter- 
vals: 

Z = {i : 3a, b G Z 9 a < b and i = [a, 6]}. 

A second sentence was added to the remark below 
the definition of Z. 

9. On page 20, the remark following the definition of “se- 
quence” (Definition 21) replaced the following original 
remark: 

Note that the first element of a sequence has index- 
value 0, and that no index value between the first and 
the last is skipped. 

10. On page 20, after the definition of len (Definition 23), 
the remark was expanded and the unneeded definition 
of ’’Set of all n-tuples“, formerly in the original text, 
was deleted. 

11. On page 21, the third line of the definition of the max 
function (Definition 31) replaced the following line of 
the original definition: 

V bounded and closed subset Q G R, 3x G Q 9 

12. On page 21, the third line of the definition of the min 
function (Definition 32) replaced the following line of 
the original definition: 

V bounded and closed subset Q G R, 3a; G Q 9 


13. On page 23, the last sentence of the definition of C 
(Definition 53) replaced the following original last sen- 
tence: 

p is said to be a prototype event if and only if 3 u G 

U 0 9 (*,p) G C(u). 

14. On page 24, the definition of M type (Definition 58) re- 
placed the following original definition: 

Mtype'- Ro —*• S*(H*(M)) 9 
Vr = (n, . . . ,rir) G R 0 , 

M ty pe(r) = £ G S*(S*(M)) 4* 

(a) [iGN,K len(£)] => &[1] = r 2 and &[2] = r 4 

and 

(b) [i,j gN ,i < j < len(£)] => 

[&[4Ui[5]] < fe[4],&[5]] 


15. On page 24, the definition of tref (Definition 60) re- 
placed the following original definition: 

tref: R 0 x M > Z 9 

(r = (n, . . . ,n 7 ),p = (pi, . . . ,p 5 )) G R 0 x M, 
Pi = r 2 ,p 2 = r 4 , 

[r 4 = “NIL” =>t p = r 15 ] , 

[r 4 ^ “NIL” =>t p = M T (r 8 , p) + r 6 ] => 
tref(r, p) = t p 

16. On page 26, the definition of skipsat R (Definition 66) 
replaced the following original definition: 

skipsat R " : 0 x R 0 — y M 9 

{Q,r = (n, . . .,r 17 )) G 0 x Ro, 
n = len(M skips (r, 0)), 

Q = jp: 3j, k G N 9 j < n, k < len(r 3 ), 


P&Cl 
P G 


PRM 

0 


k, r, Mtype (r) M skips (r, 0) [j] 


h = max 


({10- 3 , |Q|}) 


skipsat R *(0, r) = nh 


-l 


17. On page 34, the last part of the paragraph under the defi- 
nition of swappeionu (Definition 1 14) replaced the fol- 
lowing original wording: 

... prototype-event instantiations for r belonging to O' . 


18. The last part of the paragraph under the definition of 
swapearlypeionr (Definition 115, page 34) replaced 
the following original wording: 

... and a randomly selected mission event instance of 
type r 4 all prototype-event instantiations for r earlier 
than m belonging to 0 are swapped with all prototype- 
event instantiations for r earlier than m belonging to O' . 
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19. The last part of the paragraph under the definition of 
swapmidpeionr (Definition 1 16, page 34) replaced the 
following original wording: 

... and two randomly selected mission event instances 
p and // of type r,\ all prototype-event instantiations 
for r inclusively between // and /j* belonging to 0 are 
swapped with all prototype-event instantiations for r 
earlier than m belonging to 6' . 


20. On page 34, the definition of rndsvcs (Definition 117) 
replaced the following equivalent but less straightfor- 
ward original definition: 

rndsvcs: N 2 x R 0 x M — > p(N x A 0 x N 2 ) 9 
V(n, k,r = (n,..., r 17 ),n = (/zi, . . . , /z 5 )) G 
N 2 x R 0 x M , 

(ip, a, s, d ) G rndsvcs(n, k, r, ji) => 

= r 2 ,/z 2 = r 4 ,fc < len(r 3 ),n < len(r 3 [fc]), 
t p = tref(r, /z), 


Q = |(f P , a, s*, d* ) € N x A 0 x Z x N: 
3/z v G M 9 

(■ tp,a,s*,d *) £ }'max( r J k,n,fi, /z v ) j, 
(f p , a, s', d') = rndmember((5), 
(•,s“,s + ,*,d+) = r 3 [fc][n], 


C =[s\(s' + d')}n[ s -,(s+ + d+} 


s = mdint(C , (C + -d )), 
d ma * = min({d+, (£ + - s)}), 
d = rndint(d _ ,d max ) 


21. The explanatory paragraph under Section 5 (page 35) 
was expanded. 


22. In the original specification of Algorithm 2 in Sec- 
tion 6.3 on page 38, all occurrences of •* (that is, 
used as a superscript) were deleted. This change is ty- 
pographical, for the purpose of simplification only, and 
does not alter the meaning of the algorithm specifica- 
tion. 


23. The last paragraph of Subsection 8.2 on page 42 is a re- 
mark added to the original text. 

24. The definition of D 0 (Definition 131) replaced the fol- 
lowing original definition of D$: 

D 0 = {x : 3n £ N 9 x £ N"} 
and was moved to the end of Subsection 11.1.2 on 
page 49. 

25. On page 51, item 1 in the definition of -Frandomseiection 
(Definition 133) replaced the following original item 1 
in the definition: 

codomain(/) C p(0 sce „ a rio(<5, t))- 


The remarks below the definition replaced the follow- 
ing original remark: 

Note that this function is a “pseudo function” (see 
remark below Definition 17 (page 20)). 

26. On page 53, the first line of the definition of G (Defini- 
tion 136) replaced the following first line of the original 
definition of G : 

G C A x T x N+ x [0, oo) x (N+) 3 x (p(0)) N+ x 
[l,oo) e x 

27. In Subsubsection 11.4.3, page 54, the two enumerated 
items were reworded preserving the intended meaning. 

28. In Subsubsection 11.5.1.3, page 58, the last two sen- 
tences of the original text were revised. 

29. In Subsubsubsection 11.4.5.2, page 57, the symbol v 
replaced the symbol (z/j) in the second sentence of the 
fourth paragraph. 

30. Definition 146 (page 60) replaced the following origi- 
nal definition: 

A function / £ D^° is said to model Q C Dl if 
and only if 

(c,e) G Q => /(c) = e 

3 1 . The first line of Definition 148 (page 60) replaced the 
following first line of the original definition: 

D: Ax p(T) x codomain(A) -9 p{D^) 9 

32. In Subsubsubsection 1 1.5.2, page 59, the first paragraph 
is a revised version of the original first paragraph, and 
the third paragraph is a revised version of the original 
third paragraph. 
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<, 20, see interval, ordering relation, see interval, sets of in- 
tervals, ordering relation 
A*, 21 , see antenna 
Aq, 21, see antenna 
A r , 60, see regression analysis 

C, 23, see prototype communications event 
C' ( PRM , 26 

D, 60, see training data 
D 0 , 50 

^crossover i 52 

^fitness, 51, see fitness, function 
^mutation i 52 
e randomselection - 51 

/’MKTA • 55 
Tnew-g? 55 

G, 53, see Type-G, problem 
^scenario i 53 

I, 22, see potential interference interval 

L, 22, see communications link 
L*, 21, see communications link 
/.o, 22, see communications link 

M , 22, see mission event 

M* , 21, see mission event type 
Mikips, 24, see mission event 
M t yp e , 24, see mission event type 
Mi, 24, see mission event 

O, 21, see outage interval 

P, 21, see POCC operation period, see POCC 
_P max , 25, see POCC operation period 

Ro, 23, see user requirement 

S 0 , 21, see Ground Network, see Space Network, see station 

,S' 0 SA , 21 

U, 24, see user 
U 0 , 21, see user 

V, 22, see communications view period 
VPsteps, 53 

X ' , 19, see function 
Y, 23, see service 

Y y , 24, see communications view period, see service instan- 
tiation 

Y 1 , 24, see service instantiation 
Y 1 25 

x max’ 

[•, •], 19, see interval 

A, 50, see problem domain of Type G, see Type G, problem 
domain 

Adimj 50 

T, 38, 50, see Type-G, problem scenario 
Tdim, 50 

A, 40, 59, see characterization function 


0, 19, see empty set 
f2, 19, see universe of discourse 
19, see set of all finite sets 
4 1 , 23, see priority 
$o, 22, see priority 

0, 26, see schedule, 50, see Type-G, problem scenario 
0rnd, 35 
©scenario^ 50 
T, 60 

S, 20, see sequence, of all members of a finite set without re- 
peats 

3**, 20, see sequence, of some members of a set allowing re- 
peats 

3*, 20, see sequence, of some members of a set without re- 
peats 

\, 19, see set, difference 
•, 19 

o, 19, see function, composition 
k gn , 29 
k sn , 28 

(•), 20, see sequence, see tuple 
N, 19 
N+ 19 

M, 19, see real numbers, set of all 
Z, 19 

Z, 19, see interval, set of all integer intervals 
ij), 38 
J, 31 

MAXALLOWEDRTNRATE, 22 

RND, 21, see random, subset of finite set, see set, random 
subset 
S, 21, see string 
chngsvcant, 33 
chngsvcdur, 32 
chngsvcsta, 32 

codomain, 19, see function, codomain 

cutexcesspei, 33 

dom, 19, see function, domain 

endpts, 28 

endpts seq , 28 

end p , 27 

fitness, 32 

fitness*, 38 

interf*, 28 

len, 20 

maxsepsat 1 ’ , 27 

max, 21, see set, maximum value of 

minsepsat , 27 
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min, 21 , see set, minimum value of 

modsvc, 32 

replacepei, 33 

resourceusage, 28 

rndint, 20, see random, integer 

rndmember, 20, see set, random member 

rndpeis, 35 

rndpei, 32 

rndsvcs, 34 

rndsvc, 32 

rtndatarate COMBINED , 3 1 

satisfied ,31, see user requirement, satisfaction 

satisfied™ 1 , 3 1 

satisfied 11 , 31 

schedolpairs, 27 

skipsat R . 26 

skip FILL R \ 26 

slipsvc, 32 

start p , 27 

stnsw PEI , 30 

swapearlypeionr, 34 

swapmidpeionr, 34 

swappeionr, 33 

swappeionu, 34 

swappei, 33 

tref, 24, see mission event 
usage STATION SA ENDPTS 30 
violations™ ENDPTS ,29 
violations™, 30 
violations MAXSEP * , 27 
violations MINSEP * , 27 
violations RTNRATE , 31 
violations SAENDPTS , 30 
violations SA , 30 
violations SKIP *, 26 
violations™*™ 27 


violations 


SN-ENDPTS 
,,SN 


,29 


violations , 29 
violations STATIONSAENDPTS 
violations STNSW , 30 
violations™" 8 , 29 
violations™ 0 ™ 8 , 29 
violation RTNRATE , 31 
| • |, 19, see cardinality 
p, 19, see power set 
+ , 20, see interval, endpoint 
~ , 20, see interval, endpoint 


, 30 


A regr 


,60 


/estimation, 59—61, 65 


/g-i 


g-execute' 
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x , see Cartesian product 


algorithm, 8, 35, 38, 61 

Algorithm 3: Scheduling Problem Optimal-Internal- 
Parameters Estimation, 41 
Algorithm 2: S* Problem, 38 
Algorithm 4: Type-G Problem, 53 
Algorithm 5: G** Problem, 61 
Algorithm 1 : Optimal-Schedule Generation, 35 
antenna, 5, 10-13, 16-18, 21, see A*, see Aq 

cardinality, 19, see | • | 

Cartesian product, 19, 20 
characterization function, 59, see A 

CLASS, 8, see Communications Link Analysis and Simula- 
tion System (CLASS), 17, 22 
codomain, 19, see function 
communications event window, 23, 24 
communications link, 21, see L* , 22, see L, see L 0 
Communications Link Analysis and Simulation System, 8, 
17, 22 

communications view period, 16, 17, 22, see V, see Y v 
computer, 8, 13, 15, 42, 43 
quantum, 13 

run time, 38, 53, 56, 57, 62 
constraints, 5, 7, 8, 1 1-13, 29, 43 

GN Lorward and Return, 28, see k™ 

SN Lorward and Return, 28, see «:‘ SN 
Space Network resource usage, 28, see n SN 
crossover, 13, 32, 52, see /’crossover 

domain, 19, see function 

empty set, 19, see 0 
evolutionary algorithms, 13 

evolutionary search, 8, see genetic algorithm, see probabilis- 
tic search, 9, 13-15, 39, 49-51, 54, 55, 57, 59 

fitness, 32, 37, 38 

function, 32, 51, see Fatness 
S : problem, 38, see fitness* 

Type-G problem, 50 
function, 19, 20, see X Y 

codomain, 19, see codomain 
composition, 19, see o, 55 
domain, 19, see dom 

G # , 49, see Type-G, meta problem, 54 
G : problem, 56 

optimization, 56 

G ## , 49, see Type-G, meta problem, 54 
G** problem, 61 
algorithm, 61 
regression, 61 
G-algorithm, 53, 56 
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genetic algorithm, 8, see evolutionary search, 13-15, 37, 50, 
54 

internal parameters, 15 
Ground Network, 5, 8, 21 

hypersurface, 15, 40, 42, 60, 65 
fitting, 55 

index, 20 

sequence, 20 
tuple, 20 

interference, 5, 7, 8, 10, 13, 17, 18, 22, 23, 42, 43, 65 
interference instance, 28, see interf 

internal parameters, 9, 15, see genetic algorithm, internal pa- 
rameters, 35, 37-43, 46, 49, 54-57, 59, 61, 64, 65 
estimation, 40, see S iz Problem, 58, see G :: Problem 
estimation function, 9, 40, 41, 44, 55, 58, 59, 65 
optimization, 15, see G : , 37, see S' 
interval, 19, see [•, •], 20 
endpoint 
+,20 
",20 

ordering relation, 20, see < 
set of all integer intervals, 19 
sets of intervals 

ordering relation, 20, see < 

law of diminishing returns, 46 

mapping, 19, see function 
meta problem, 54 

meta-problem scenario, 55, see meta, 56, see Type-G, meta 
problem, 58 

method, 8 

mission event, 22, see M, see tref, see A/ skips , see Mj 
mission event type, 21, see M*, 24, see M t ype , 26 
model, 9, 40, 47—19, see regression analysis, 59, 60, 65 
mutation, 13, 32, 52, see -F mu tation 

optimal, 8-10, 12-16, 35, 37, 38, 40-44, 46, 49 
optimization, 8, 9, 13-15, 37—44 

recursive, 56, see recursion, 57, see recursion 
optimum, 13, 37, 39, 57 
ordered pair, 20, see tuple 
outage interval, 18, 21, see O 

POCC, 17, 18 

POCC operation period, 21, see P, 25, see P max 
potential interference interval, 18, 22, see I 
power set, 19, see p 
priority, 18, 22, see <t>o, see $ 

probabilistic search, 13-16, 37, see evolutionary search, see 
genetic algorithm, 55 


problem domain of Type G, 50, see A 
problem scenario, 50, see T 

characterization function, 59, see A 
dimension, 50, see Tdi m 
meta, 54, 58 
Type-G, see T, 58 
process, 8 
process models, 43 
prototype event, 23, see C, 66 
prototype-event instantiation, 26, see Cq RM 
pseudo function, 20, 51-53 

random, 14 

integer, 20, see rndint 

member of a finite set, 20, see rndmember 

number, 14, 16 

selection, 5 1 

subset of finite set, 21, see RND 
real numbers, set of all, 19, see R. 
recursion, 56, 57, 61 

regression analysis, 9, 13, 40-42, 59, 60, see A r , 61, 63-65 

requirement, 22, see user requirement 

run time, 8, see computer, run time, 38, 46, 48 

S ## , 38, 40 

problem, 37 

S # , 15 , see internal parameters, optimization, 37-39 
schedule, 5, 7, 18, 26, see 0, 65 
optimized, 43 

scheduler, 7, 8, 13, 18, 42, 43 
optimizing, 7-9, 43, 44 
scheduling 

objective, 26 

system, 7, 9, 13, 16, 17,41-43 
sequence, 20, see also tuple 
elements of, 20, see (•) 
index, 20 
length, 20, see len 

of all members of a finite set without repeats, 20, see E 
of some members of a set allowing repeats, 20, see S** 
of some members of a set without repeats, 20, see S* 
subsequence, 20 
service, 23, see Y 

service instantiation, 24, see K v , see Y 1 
set, 19 

difference, 19, see \ 
maximum value of, 2 1 , see max 
minimum value of, 2 1 , see min 
random member, 20, see rndmember 
random subset, 21, see RND 
specification notation, 19 
set of all finite sets, 19, see Dp 
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skip factor, 23-26 

Space Network, 5, 8, 21 

Space Network Users’ Guide, 28 

station, 21, see Ground Network, see Space Network 

string, 2 1 , see S 

test data, 41, see training data, 65 

training data, 41, 60, see D, see G**, see regression analysis, 
63 

tuple, 20, see also sequence, see (•) 

Type-G, 50, 53, 64 

meta-problem, 49, see G*, see G : \ 54-59, 63 
chain, 56, 57 
problem, 53, see G, 58 
problem domain, 50, see A, 59 
problem scenario, 50, see I , 58, 64 

universe of discourse, 19, see LI 
user, 5, 7, 8, 10-12, 18, see Uq, see U 
user requirement, 14, 17, 18, 22, 23, see Rq, 24 
generic, 22 

satisfaction, 16, 31, see satisfied 
specific, 22 
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